I don't trust a web framework that's opinionated about how I use my database.
It's very hard to get a web framework right, and it's very hard to get an ORM right. Getting both right is nearly impossible. In a situation like this, try to be the best web framework you can be, and then gravitate towards whatever ORM(s) becomes popular.
Take a look at Express for Node.js. It's my favorite web framework because it can both do a lot, and it's very transparent. It's also not opinionated about things like the ORM.
> web framework for lazy developers
Rust is not a language for lazy developers. (Lazy developers won't fight with the borrow checker.) Instead, think more critically about why a Rust developer would need a web framework; and what they need out of it.
Rust already has several server frameworks that are relatively low-level network plumbing, and leave figuring out everything else to the user.
If that's what you like, you can pick and choose from all the existing tools.
The Rust's ecosystem is now missing its Rails or Django.
This is an attempt to make something for those "lazy" devs who don't want to write their own cookie parsing middleware, and figure out how to get a database connection pool working with a request router.
There’s https://loco.rs/ if you like that sort of Rails experience. Personally I’ve grown more fond of having little cruft in my apps, being “lazy” about what goes into the code isn’t right to me and many of these frameworks don’t really care about that. To me most of the value in these opinionated frameworks is in the scaffolding anyway, not the opinions.
The incredible proliferation of Rust web frameworks should be an almost blinding beacon advertising how well-suited Rust is for web backend development.
The biggest takeaway that anyone new to Rust or new to Rust-on-backend should have: Rust absolutely rocks for backend development. It's getting a tremendous amount of attention, people are trying a lot of things, and it's crystalizing as a major backend powerhouse.
You can be just as performant in Rust as you can in Go, or frankly, Python, and the result is super typesafe, super ergonomic, and blindingly fast. Google recently published a paper that said as much.
Rust already has several Python Flask equivalents (Actix/Axum), and it's waiting on its Rails/Django framework.
For anyone scared of Rust or the borrow checker: due to the nature of HTTP services and request flow logic, you almost never bump into it when writing backend Rust. But if you ever need to write anything with multiple hand-rolled threads or worker pools, you can. Rust opens up a lot of interesting possibilities, such as rich in-memory databases. But you certainly don't have to use these powers either if you don't need them.
> For anyone scared of Rust or the borrow checker: due to the nature of HTTP services and request flow logic, you almost never bump into it when writing backend Rust.
I’d say for anyone worrying about it just use ‘clone()’ everywhere you can. If you’re coming from any interpreted language the performance and efficiency will just be so much better that it doesn’t matter.
Opinionated frameworks are very useful. They create well-worn paths that others have tried before.
Every python flask environment I've ever seen has been a bespoke configuration with some selection of the massive combinatoric space that flask presents to folks.
Contrast that with python Django or Ruby on Rails where opinions abound, but you can escape the well worn path if you _need_ to.
Honestly as someone who has been building Rails applications for over 15 years now, I find far too many people think they are special and need to stray from the defaults.
In my experience, most people who say “we don’t need no stinkin’ framework” end up basically inventing their own framework. Most of the time, it’s also just flat out worse.
As such, my initial gut reaction is to quell the NIH syndrome.
Backend development is all about data storage and retrieval. It's no coincidence that the most celebrated backend frameworks of all time developed best-in-class ORMs for their respective languages. Being able to define a single structure that defines how data moves all the way through the stack is incredibly powerful and opens up development optimizations that simply don't happen when mixing boutique libraries.
> Lazy developers won't fight with the borrow checker.
You don't fight the borrow checker when writing web code. The request flow is well suited for rarely, if ever, testing the borrow checker.
> Instead, think more critically about why a Rust developer would need a web framework
The same reason anyone would need a web framework. Anything ranging from bullshit hack to high SLA service.
I'm finding Rust to be a drop-in Go and Python replacement for HTTP. It's really good at this use case, and it's certainly something you can be very lazy about with modern Rust web frameworks.
It's absolutely not true, the moment you're out of http hello word, and you have more serious logic about data that you need to manipulate / modify you will fight the borrow checker, that's why a lot of people do a lot of rc / arc refcell.
I really wish Rust projects would stop using the term "blazing speed". It is almost like a meme already. You can write slow code in Rust pretty easily, so speed is something extra.
And I am a Rust developer... Seeing this term makes me cringe every time.
Ditto for "type safety". This always feels like reaching for onnnne more feature on these project hype sites. "I don't expose the public API as Any!" feels about on the level of "has documentation"... which they also pitch as a feature.
I'd describe this more as a batteries-included Axum, which is fine on it's own. Don't compare it with Django in this stage, because if I'm being honest, the examples aren't very snappy.
I love the idea and I've toyed around with a Symfony/RoR framework in Rust, but other projects like loco.rs are already doing god's work, so I saw no reason to design another wheel.
The README itself says it should feel familiar to Django, which it certainly does from a developer API perspective based on my cursory review of the guide
I think Rails caters to a specific type of audience. Personally, I hate the idea of "scaffolding" my app. I'm fine just writing that plumbing code and seeing how all the pieces interact.
And I never understand this "just accept the status quo" take. If we all did that, we'd still be nomads living in caves.
> “Cot” is pronounced similarly to a Polish word “kot”, which means “cat”. Cats are known for their agility and flexibility, and also this is where the logo comes from.
Also, if I might add, the author's last name (Maćkowski) seems to be related to the word used for "cat" in several Slavic languages (e.g. Croatian: https://hr.wikipedia.org/wiki/Doma%C4%87a_ma%C4%8Dka), though apparently not in Polish...
This looks great. One of the glaring holes in the ecosystem is a good ORM like Django or ActiveRecord; Diesel is simply more barebones. This looks like it’s a candidate for capturing the ease of use that these offer.
I'm still surprised no one in the golang world has put together a Django type framework. While I like the bring-your-own unixy philosophy of this stuff in the go world; I still really loved django for quick decent applications.
I do not understand how async/await got introduced into a language with no garbage collector.
The mountains Rust has to move, in invisible magical ways, to get the tokio runtime to work without a garbage collector is deeply disturbing (`pin` anyone?)
I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector?
But what gets me most is that asynchronous programming is not hard (harder than it should be in Rust due to the absence of non-blocking file handles....) and async/await makes the easy things a bit easier, whilst making some difficult things very very difficult.
The trade offs are all wrong, it is very popular and widely used.
> I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector?
Because a garbage collector does not have an invisible runtime: The memory model is tightly coupled with the garbage collector. This is not zero-cost. All garbage collection comes with some cost; although for many kinds of programming it's so "worth it" that we don't need to consider alternatives.
As someone who's spent most of my career using garbage collected languages; I both appreciate the advantages that come with the tradeoffs of garbage collection; and the tradeoffs that come with Rust. Rust has no runtime memory management overhead, and no complicated framework to ship.
I still personally don't understand "why" async Rust is so hard. I struggled trying to use it, but at the time I was such a Rust novice that I "didn't know what I didn't know." Yes, async Rust would be easier if the language was garbage collected; but that defeats the point of Rust.
Rust excels at things like command-line utilities, or high-performance libraries (that don't require you to suck in a whole framework.) In these cases, the case for "async" isn't strong, because chances are there isn't enough concurrent IO to for async vs threaded to make a difference.
If you're making a web application, chances are you're hosting it yourself. Thus, you don't have to "ship" your software and compel your users to load up whatever framework(s) you choose. IE, you can choose to use C# or Node.js, and decide that it's worth your time to spend more on hosting.
Heterogeneous selects are just not possible to do in a cross-platform manner, without async/await. Rust is one of the very few environments which lets you do them in a reasonable manner -- the other alternatives are a nest of threads or a hand-written message loop-based state machine, both of which don't scale well as complexity goes up.
> ORM integration
I don't trust a web framework that's opinionated about how I use my database.
It's very hard to get a web framework right, and it's very hard to get an ORM right. Getting both right is nearly impossible. In a situation like this, try to be the best web framework you can be, and then gravitate towards whatever ORM(s) becomes popular.
Take a look at Express for Node.js. It's my favorite web framework because it can both do a lot, and it's very transparent. It's also not opinionated about things like the ORM.
> web framework for lazy developers
Rust is not a language for lazy developers. (Lazy developers won't fight with the borrow checker.) Instead, think more critically about why a Rust developer would need a web framework; and what they need out of it.
Rust already has several server frameworks that are relatively low-level network plumbing, and leave figuring out everything else to the user. If that's what you like, you can pick and choose from all the existing tools.
The Rust's ecosystem is now missing its Rails or Django.
This is an attempt to make something for those "lazy" devs who don't want to write their own cookie parsing middleware, and figure out how to get a database connection pool working with a request router.
There’s https://loco.rs/ if you like that sort of Rails experience. Personally I’ve grown more fond of having little cruft in my apps, being “lazy” about what goes into the code isn’t right to me and many of these frameworks don’t really care about that. To me most of the value in these opinionated frameworks is in the scaffolding anyway, not the opinions.
> Rust already has several server frameworks
The incredible proliferation of Rust web frameworks should be an almost blinding beacon advertising how well-suited Rust is for web backend development.
The biggest takeaway that anyone new to Rust or new to Rust-on-backend should have: Rust absolutely rocks for backend development. It's getting a tremendous amount of attention, people are trying a lot of things, and it's crystalizing as a major backend powerhouse.
You can be just as performant in Rust as you can in Go, or frankly, Python, and the result is super typesafe, super ergonomic, and blindingly fast. Google recently published a paper that said as much.
Rust already has several Python Flask equivalents (Actix/Axum), and it's waiting on its Rails/Django framework.
For anyone scared of Rust or the borrow checker: due to the nature of HTTP services and request flow logic, you almost never bump into it when writing backend Rust. But if you ever need to write anything with multiple hand-rolled threads or worker pools, you can. Rust opens up a lot of interesting possibilities, such as rich in-memory databases. But you certainly don't have to use these powers either if you don't need them.
> For anyone scared of Rust or the borrow checker: due to the nature of HTTP services and request flow logic, you almost never bump into it when writing backend Rust.
I’d say for anyone worrying about it just use ‘clone()’ everywhere you can. If you’re coming from any interpreted language the performance and efficiency will just be so much better that it doesn’t matter.
That's an excellent way to get your footing. And you can come back in a month and fix it all easily.
clone(); )?; all that stuff is just meh.
Opinionated frameworks are very useful. They create well-worn paths that others have tried before.
Every python flask environment I've ever seen has been a bespoke configuration with some selection of the massive combinatoric space that flask presents to folks.
Contrast that with python Django or Ruby on Rails where opinions abound, but you can escape the well worn path if you _need_ to.
Honestly as someone who has been building Rails applications for over 15 years now, I find far too many people think they are special and need to stray from the defaults.
In my experience, most people who say “we don’t need no stinkin’ framework” end up basically inventing their own framework. Most of the time, it’s also just flat out worse.
As such, my initial gut reaction is to quell the NIH syndrome.
Iterators, type safety, built-in CI & CD & Linting, and the borrow checker are exactly for lazy developers in my opinion.
Who wants to fight with C?Make Bazel Ninja?
Backend development is all about data storage and retrieval. It's no coincidence that the most celebrated backend frameworks of all time developed best-in-class ORMs for their respective languages. Being able to define a single structure that defines how data moves all the way through the stack is incredibly powerful and opens up development optimizations that simply don't happen when mixing boutique libraries.
It's probably not for you, it is absolutely for me. I am looking for a micronaut for Rust.
There are many options to build your own thing on hyper | axum | tonic | tower if you want.
> Rust is not a language for lazy developers.
I am one, and Rust absolutely can be.
> Lazy developers won't fight with the borrow checker.
You don't fight the borrow checker when writing web code. The request flow is well suited for rarely, if ever, testing the borrow checker.
> Instead, think more critically about why a Rust developer would need a web framework
The same reason anyone would need a web framework. Anything ranging from bullshit hack to high SLA service.
I'm finding Rust to be a drop-in Go and Python replacement for HTTP. It's really good at this use case, and it's certainly something you can be very lazy about with modern Rust web frameworks.
It's absolutely not true, the moment you're out of http hello word, and you have more serious logic about data that you need to manipulate / modify you will fight the borrow checker, that's why a lot of people do a lot of rc / arc refcell.
And then the async implementation.
I’m writing a web app at work and I have one Arc and no Rc or RefCell.
Got zero because I cheated with Box::leak
Haha!
I would have thought async would be the biggest problem.
If you're in a web framework, all the handlers are async already. You have literally no work to do.
Show me what you find to be hard, because I don't believe you.
None of what you've described is hard. It's quite approachable, and an IDE with an LLM practically autocompletes everything for you anyway.
If you can write Java or Go, you can absolutely write Rust.
As someone who has written a fair bit of web service code in Rust over the last 5 years or so, this is all correct.
On the website:
> Cot empowers you to build production-ready web apps in record time
In github:
> Cot is currently missing a lot of features and is not ready for anything even remotely close to production use.
To be fair, that was added on Jan 20. A whole lot could have changed in a month ;) https://github.com/cot-rs/cot/commit/19b1d897e0af20616a4afa4...
Too late, it’s probably alteady used in prod at many F500 companies ;)
I really wish Rust projects would stop using the term "blazing speed". It is almost like a meme already. You can write slow code in Rust pretty easily, so speed is something extra.
And I am a Rust developer... Seeing this term makes me cringe every time.
> And I am a Rust developer... Seeing this term makes me cringe every time.
I write blazingly fast statically allocated Rust on my Arch Linux Thinkpad, btw.
If not a joke can you explain what is statically allocated rust
It is an actual intentional meme, not “almost like” one.
Ditto for "type safety". This always feels like reaching for onnnne more feature on these project hype sites. "I don't expose the public API as Any!" feels about on the level of "has documentation"... which they also pitch as a feature.
I personally like to explicitly know beforehand if a JavaScript or Python package comes with type annotations, which is not a given.
I’ve read the term “type-safe HTML” somewhere, still have no idea what that means.
I'd describe this more as a batteries-included Axum, which is fine on it's own. Don't compare it with Django in this stage, because if I'm being honest, the examples aren't very snappy.
I love the idea and I've toyed around with a Symfony/RoR framework in Rust, but other projects like loco.rs are already doing god's work, so I saw no reason to design another wheel.
The README itself says it should feel familiar to Django, which it certainly does from a developer API perspective based on my cursory review of the guide
I think Rails caters to a specific type of audience. Personally, I hate the idea of "scaffolding" my app. I'm fine just writing that plumbing code and seeing how all the pieces interact.
And I never understand this "just accept the status quo" take. If we all did that, we'd still be nomads living in caves.
So use axum and do whatever you want? Or better yet, hyper?
Discussed three days ago:
- https://news.ycombinator.com/item?id=43089468
From the FAQ:
> “Cot” is pronounced similarly to a Polish word “kot”, which means “cat”. Cats are known for their agility and flexibility, and also this is where the logo comes from.
Also, if I might add, the author's last name (Maćkowski) seems to be related to the word used for "cat" in several Slavic languages (e.g. Croatian: https://hr.wikipedia.org/wiki/Doma%C4%87a_ma%C4%8Dka), though apparently not in Polish...
This looks great. One of the glaring holes in the ecosystem is a good ORM like Django or ActiveRecord; Diesel is simply more barebones. This looks like it’s a candidate for capturing the ease of use that these offer.
I'm still surprised no one in the golang world has put together a Django type framework. While I like the bring-your-own unixy philosophy of this stuff in the go world; I still really loved django for quick decent applications.
I am too lazy to deal with Async at this time.
I do not understand how async/await got introduced into a language with no garbage collector.
The mountains Rust has to move, in invisible magical ways, to get the tokio runtime to work without a garbage collector is deeply disturbing (`pin` anyone?)
I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector?
But what gets me most is that asynchronous programming is not hard (harder than it should be in Rust due to the absence of non-blocking file handles....) and async/await makes the easy things a bit easier, whilst making some difficult things very very difficult.
The trade offs are all wrong, it is very popular and widely used.
Reminds me of Microsoft in 1997
> I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector?
Because a garbage collector does not have an invisible runtime: The memory model is tightly coupled with the garbage collector. This is not zero-cost. All garbage collection comes with some cost; although for many kinds of programming it's so "worth it" that we don't need to consider alternatives.
As someone who's spent most of my career using garbage collected languages; I both appreciate the advantages that come with the tradeoffs of garbage collection; and the tradeoffs that come with Rust. Rust has no runtime memory management overhead, and no complicated framework to ship.
I still personally don't understand "why" async Rust is so hard. I struggled trying to use it, but at the time I was such a Rust novice that I "didn't know what I didn't know." Yes, async Rust would be easier if the language was garbage collected; but that defeats the point of Rust.
Just to follow up a bit:
Rust excels at things like command-line utilities, or high-performance libraries (that don't require you to suck in a whole framework.) In these cases, the case for "async" isn't strong, because chances are there isn't enough concurrent IO to for async vs threaded to make a difference.
If you're making a web application, chances are you're hosting it yourself. Thus, you don't have to "ship" your software and compel your users to load up whatever framework(s) you choose. IE, you can choose to use C# or Node.js, and decide that it's worth your time to spend more on hosting.
Heterogeneous selects are just not possible to do in a cross-platform manner, without async/await. Rust is one of the very few environments which lets you do them in a reasonable manner -- the other alternatives are a nest of threads or a hand-written message loop-based state machine, both of which don't scale well as complexity goes up.
https://crates.io/crates/mio
Right, which (if you use it without Tokio) means you're managing a message loop by hand. Doesn't quite scale up to state machines with 50+ states.
> Doesn't quite scale up to state machines with 50+ states.
It is a lot of lines of code, but simple.
It is the easy thing.
Jesus fucking christ not this again.
https://without.boats/blog/why-async-rust/
There are entire articles explaining precisely why. Your lack of knowledge contributes very little to an article about a framework.
That article assumes that there needed to be language level support for asynchronous programming, beyond non-blocking operations.
My point is that that is not true.
If you want to use the blocking paradigms for asynchronous programming, then yes, there does need to be some magic added to make it work.
If, however, you are comfortable with asynchronous programming (and it is not hard) then all you need are the non-blocking operations.
I mean the name Reinhardt was RIGHT there.