Cot: The Rust web framework for lazy developers
cot.rs
cot.rs
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.
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.
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.
Who wants to fight with C?Make Bazel Ninja?
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.
As such, my initial gut reaction is to quell the NIH syndrome.
Imagine if your framework said,"let a thousand flowers bloom."
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.
And then the async implementation.
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.
There are many options to build your own thing on hyper | axum | tonic | tower if you want.
Once you get the hang of it, it's not a big effort any more. And the really lazy option is to just use an Arc.
> 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.
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.
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.
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...
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
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.
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.
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.
No!
* 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)
It is a lot of lines of code, but simple.
It is the easy thing.
Django users who would still consider an RIIR web framework, and those who are even aware of the guitar player.