[sgeisenh]

I'm not sure that it's that cut and dry. Rust provides good tools for building high level abstractions and the developer tooling is comparable to something like typescript. Depending on the team, rust can be a perfectly reasonable choice for a CRUD application.

I have a lot of experience writing microservices and batch jobs using C++. At first this seems outrageous, but with a reasonable set of high level utility libraries, C++ can be very expressive. And then you have the option to drop down to whichever level of abstraction is necessary to address performance or concurrency issues.

Beyond platform requirements (e.g. HTML, CSS and JS on the web or python for ML) I think language choice has more to do with business needs than high level problem domain. When you're building an MVP or have an urgent business need where you need to prioritize short term progress over long term flexibility, high level languages with GC are great. If you have an experienced team and you want to build something that will offer flexibility in the long term, Rust is a fine choice.

[cjglo]

Doesn’t Kotlin or Swift offer those things?

I agree Rust is a great language (and has many great things besides its safety protections) but I do think that putting it everywhere when it isn’t necessary is dangerous.

If one doesn’t exist already, someone should make a rust-like language with garbage collection.

EDIT: Thanks to reading other comments, I remembered Elixir, which offers a lot of the concurrency safety of rust without the memory risks.

[nicoburns]

Kotlin is probably also a good choice (but it ties you do the JVM, which does come with some operational headaches of it's own). Swift would be a fantastic language for this kind of work, but unfortunately it's library ecosystem isn't on nearly the same level as Rust's for backend web.

[sgeisenh]

Rust is an interesting mix. OCaml gets pretty close and type inference offers better ergonomics. The fearless concurrency story is still much better in Rust than OCaml.

[marcosdumay]

Yes, it's a completely clear cut.

If you want high level abstractions, well, automatic memory management enables a bunch of abstractions that the Rust developers gave up on long ago. There are languages with many more capabilities than the ones Rust gives you.

If you have a high level problem, you don't want to spend your focus on low level issues.

[zozbot234]

> automatic memory management enables a bunch of abstractions that the Rust developers gave up on long ago.

These claims should really come with sourcing. Rust devs have been raising the potential for abstraction in Rust since the initial 1.0 release, most recently with GAT's. What's always been quite hard is zero overhead abstraction, which GC languages simply have no equivalent for.

[marcosdumay]

Sourcing for my "water is wet" claim? Just try writing a language parser in Rust and Haskell and you'll see the difference. Or, to be more on topic, write some database to HTML on Rust and note how you have to keep track of your templates' lifetimes.

The Rust developers are a bunch of very smart people working hard on creating a great language, but they can't do impossible things.

[steveklabnik]

I have written HTML templates and never had to keep track of lifetimes. Do you have an example of how that happens?

[polio]

Batch jobs seem like a good candidate for C++ because of how much faster a single instance will be. Multiplied across the size of the total job, that can represent enormous savings. On the other hand, using Rust for a web server with low QPS and atop a relatively novel web stack seems unnecessarily risky. The article does comment on Actix being a pain point.

My current job doesn't use Rust at all, but we're experimenting with converting some CLI tools. There should be relatively little library dependence for the things we're targeting.