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.
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.
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.
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.
> 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.
Have you ever written a web app in Rust? Most of the code is in a form of handlers that receive data, process the data and give some data back. There is rarely need to think about lifetimes or borrowing in these scenarios.
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.
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.
This is true. If I'm choosing a package to use, and among the options, there's one with annotations and one without, I'll use the one with annotations unless there's a glaring feature missing. A recent example was moving from tenacity to backoff for retrying.
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...
One thing I commonly see with projects like this targeting developers is they lack code examples on their homepage. Show me some code! I want to see right away what you’re doing differently than all the other libraries/frameworks.
I want a Rust web framework for perfectionists with deadlines. Or a Go web framework for perfectionists with deadlines. Basically a Django but with much lower CPU and RAM requirements and easier deployement. Is this the spirit of Cot ?
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.
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 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.
* Window NT in 1991. Displaced much better systems, on mass
* Node.js (my job) is simply dreadful. Mass adoption there too
* It took until 2015 to get half way to a replacement for C for real time systems. C is incredibly prone to failure - and it still has mass adoption. (Very tricky that one)
Popularity is a very bad metric for choosing computer systems.
(Unless you are looking for a job - see above for Node.js)
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.