This is true in some senses, but also, response latency isn't the only thing a web application does or is evaluated by. Many applications have, for example, background jobs, that do arbitrarily complex processing outside of the request/response cycle.
Additionally, people who write web services in Rust talk about decreased memory usage, consistent memory usage, and lower CPU usage. In a cloud context, that can translate directly to revenue saved, by spending less. If that tradeoff is right for you depends on a variety of things, of course. "speed" isn't the only relevant metric that you may want to optimize for.
You are looking at ~5mb container vs 200+mb if you did a jvm based container.
It's probably overkill for most applications and companies, but it's something to keep in mind if you need fast scaling for cheap.
Not to mention you can use GraalVM native-image to compile to a binary directly, in which case it'll be even smaller.
Yeah, for sure -- I deal with a web app that does complex, time-consuming analytics in data pipelines with Python, and Rust could help a lot with improving some of the complex calculations. But again, that's more using Rust as a C++ replacement rather than looking at replacing, say, the Python-Flask frontend that serves up the results of those analytics.
> Additionally, people who write web services in Rust talk about decreased memory usage, consistent memory usage, and lower CPU usage. In a cloud context, that can translate directly to revenue saved, by spending less. If that tradeoff is right for you depends on a variety of things, of course. "speed" isn't the only relevant metric that you may want to optimize for.
It'd definitely reduce costs, but yeah, be sure to get a full picture here from a business perspective. Engineers love to optimize AWS costs, but it isn't appropriate in a lot of situations. In my case, I'm paying a nontrivial 5-figure monthly AWS bill, but if my company's AWS costs went to $0/month... it wouldn't move our death date, and it wouldn't change our valuation. This is especially true if there were any loss in developer productivity/feature releases. I would gladly double my AWS bill if I could get features out even 20% faster, though that's not how it works, obviously.
This means that you don't accidentally forget a null check (or a catch block) and, in my experience leads to software that is a lot more robust.
Even if all it is doing is pulling from a database and munging it into JSON.
In practice, every time I've tried out Ocaml, I've bounced off _hard_. The standard library is very limited and filled with cruft (stdlib regexes being a notable example), so users very quickly need to start understanding the alternatives. There's little in the way of good intermediate documentation, so once you've figured out how recursion works, it's often quite hard to figure out more practical questions, like when it makes sense to switch to refs and imperative code for a problem. There's also not a lot of "practical" libraries - I wanted to write a small web service recently to organise house chores, and I figured I'd need a decent datetime library (with support for juggling timezones), some way of interacting with sqlite, and a basic web server. The web server situation was okay, but the only SQL library I could find was 80% ungoogleable sigils with minimal documentation, and I couldn't find a single datetime library that has a concept of instances that could be interpreted in different time zones.
In contrast, Rust has a clean (albeit minimal) standard library, with a lot of good pointers to well-maintained third-party libraries; it has plenty of documentation ranging from the beginner guide to the Rustonomicon; and there's a lot of stuff happening in the ecosystem that you can already start relying on. Like, if you're coming from Java or Python you might have to lower your expectations somewhat, but you can still have expectations of _something_, which is not my experience with Ocaml.
I think I need to try out F# more - my impression is that there's at least an existing C# ecosystem there which helps with a lot of the practical issues - but so far I've been really disappointed by my experiences in ML-land. There's so much I want to like - I'm really excited about the new effects work that's happening, for example - but the ecosystem as a whole just doesn't seem that usable for practical things unless you already know what you're doing, or unless you're prepared to build all the stuff you need from scratch à la Jane Street.
So actually, in practice, I find myself much more productive in Rust, despite coming from a Python/Java/JS background. The memory management stuff turns out to be pretty easy to pick up, and having a strong ecosystem means that I've generally got the tools I need at my fingertips.
Jane Street's Core has a good timezone support (the thing you need is pair Date.t * Time_ns.Ofday.t). sqlite3-ocaml [1] seems reasonably documented.
If I do them in Rust, I would need to build from scratch and I rather not, as that isn't my focus.
Besides F#, there are also Haskell, Scala, Kotlin.
Java and C# are also getting there, even if a bit slowly, and compromised by backwards compatibility.
Rust's error handling might be great for people who are used to exception based error handling but it is a joke compare to railway oriented programming in Fsharp or any ML lang that supports |>.
_ => ()
to avoid having to handle it, but at least that's easy to pick up on in a code review.
If by casual user, you mean the 95% case of a back-end developer whose main job is pulling data from various sources, performing operations, and placing that data elsewhere and/or displaying it to an end user: nothing, really.
Rust excels at performance, but the bottleneck in modern web apps is going to be IO, whether that's loading data from a database or from a third-party API you're integrating with. Rust excels at correctness, but your errors are going to come from bad data and system outages which require manual intervention anyway. Rust excels at security, but if you're using a GC language running on a Docker container on an ephemeral cloud instance, the kind of security Rust provides isn't a likely attack vector for you.
All that being said, Rust is a great language! It just has its niche, and that niche is not the typical web-dev back-end work that most developers do these days. As others have said, you'd use Rust in the same situations you'd use C++: building a database, building a web server (like nginx), etc. If you're just building a web app that talks to a database and serves HTTP responses, stick with Python/Ruby/Go/PHP.