Comment by echelon
4 months ago
Rust is actually quite suitable for a number of domains where it was never intended to excel.
Writing web service backends is one domain where Rust absolutely kicks ass. I would choose Rust/(Actix or Axum) over Go or Flask any day. The database story is a little rough around the edges, but it's getting better and SQLx is good enough for me.
edit: The downvoters are missing out.
To me, web dev really sounds like the one place where everything works and it's more a question of what is in fashion. Java, Ruby, Python, PHP, C, C++, Go, Rust, Scala, Kotlin, probably even Swift? And of course NodeJS was made for that, right?
I am absolutely convinced I can find success story of web backends built with all those languages.
Yeah, "web services backend" really means "code exercising APIs pioneered by SunOS in 1988". It's easy to be rock solid if your only dependency is the bedrock.
> probably even Swift
It's possible to write web backends in Swift, but it's probably not a good idea. When I last did so, I ran into ridiculous issues all the time, such as lazy variables not being thread-safe, secondary threads having ridiculously small (and non-adjustable) stack sizes and there being generally absolutely no story for failure recovery (have fun losing all your other in-flight requests and restarting your app in case of an invalid array access). It's possible that some of this has been fixed in the last 5 years since I stopped working on that project, but given Apple's priorities, I somehow doubt that the situation is significantly better.
The bar for web services is low, so pretty much anything works as long as it's easy. I wouldn't call them a success story.
When things get complex, you start missing Rust's type system and bugs creep in.
In node.js there was a notable improvement when TS became the de-facto standard and API development improved significantly (if you ignore the poor tooling, transpiling, building, TS being too slow). It's still far from perfect because TS has too many escape hatches and you can't trust TS code; with Rust, if it compiles and there are no unsafe (which is rarely a problem in web services) you get a lot of compile time guarantees for free.
There are 3 cases. The first is that you are comfortable with Rust and you just choose it for that. The second is that you're not comfortable with Rust and you choose something else that works for you.
The third is the interesting one. When your service has a lot of traffic and every bit of inefficiency costs you money (node rents) and energy. Rust is an obvious improvement over the interpreted languages. There are also a few rare cases where Rust has enough advantages over Go to choose the former. In general though, I feel that a lot of energy consumption and emissions can be avoided by choosing an appropriate language like Rust and Go.
This would be a strong argument in favor of these languages in the current environmental conditions, if it weren't for 'AI'. Whether it be to train them or run them, they guzzle energy even for problems that could be solved with a search engine. I agree that LLMs can do much more. But I don't think they do enough for the energy they consume.
> Rust is an obvious improvement over the interpreted languages.
Do we agree that most of the languages I mentioned above are not interpreted languages? You seem to only consider Go as a non-interpreted alternative...
7 replies →
Perhaps. But a comparable Rust backend stack produces a single binary deployable that can absorb 50,000 QPS with no latency caused by garbage collection. You get all of that for free.
The type system and package manager are a delight, and writing with sum types results in code that is measurably more defect free than languages with nulls.
Yep, that's precisely it! When dealing with other languages I miss the "match" keyword and being able to open a block anywhere. Sure, sometimes Rust allows you to write terse abominations if you don't exercise a dose of caution and empathy for future maintainers (you included).
Other than the great developer experience in tooling and language ergonomics (as in coherent features not necessarily ease of use) the reason I continue to put up with the difficulties of Rust's borrow checker is because I feel I can work towards mastering one language and then write code across multiple domains AND at the end I'll have an easy way to share it, no Docker and friends needed.
But I don't shy away from the downsides. Rust loads the cognitive burden at the ends. Hard as hell in the beginning when learning it and most people (me included) bounce from it for the first few times unless they have C++ experience (from what I can tell). At the middle it's a joy even when writing "throwaway" code with .expect("Lol oops!") and friends. But when you get to the complex stuff it becomes incredibly hard again because Rust forces you to either rethink your design to fit the borrow checker rules or deal with unsafe code blocks which seem to have their own flavor of C++ like eldritch horrors.
Anyway, would *I* recommend Rust to everyone? Nah, Go is a better proposition for a most bang for your buck language, tooling and ecosystem UNLESS you're the kind that likes to deal with complexity for the fulfilled promise of one language for almost anything. In even simpler terms Go is good for most things, Rust can be used for everything.
Also stuff like Maud and Minijinja for Rust are delights on the backend when making old fashioned MPA.
Thanks for coming to my TED talk.
14 replies →
Yeah, anything with nulls ends up with Option<this> and Option<that> which means unwraps or matches. There is a comment above about good bedrock and Rust works OK with nulls but it works really well with unsparse databases (avoiding joins).
Tokio + Axum + SQLx has been a total game-changer for me for web dev. It's by far the most productive I've been with any backend web stack.
I prefer rusqlite over SQLx; the latter is too bloated.
People that haven't tried this are downvoting with prejudice, but they just don't know.
Rust is an absolute gem at web backend. An absolute fucking gem.
We know, it stil isn't at Spring/ASP.NET level, coupled with Scala/Kotlin/F#.
5 replies →
Curious, do you mind going into more detail on why?