[HN Gopher] Cot: The Rust web framework for lazy developers
___________________________________________________________________
Cot: The Rust web framework for lazy developers
Author : hyperbrainer
Score : 47 points
Date : 2025-02-18 14:09 UTC (3 days ago)
(HTM) web link (cot.rs)
(TXT) w3m dump (cot.rs)
| zamalek wrote:
| 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.
| czbond wrote:
| 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...
| xyst wrote:
| Too late, it's probably alteady used in prod at many F500
| companies ;)
| the__alchemist wrote:
| I am too lazy to deal with Async at this time.
| worik wrote:
| 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
| gwbas1c wrote:
| > 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.
| gwbas1c wrote:
| 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.
| iknowstuff wrote:
| 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.
| sunshowers wrote:
| 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.
| shepmaster wrote:
| Discussed three days ago:
|
| - https://news.ycombinator.com/item?id=43089468
| ramon156 wrote:
| 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.
| gwbas1c wrote:
| > 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.
| pornel wrote:
| 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.
| meltyness wrote:
| 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?
| pimeys wrote:
| 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.
| iknowstuff wrote:
| It is an actual intentional meme, not "almost like" one.
| ost-ing wrote:
| > 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.
___________________________________________________________________
(page generated 2025-02-21 23:00 UTC)