Rust has been "web ready" for some time. C++ is "web ready", too.
But why should one choose Rust when there're plenty of alternatives with much larger and much more stable ecosystems. And those alternatives offer much higher productivity and a much larger talent pool.
Rust is not even the fastest web framework (https://www.techempower.com/benchmarks/) . And the benefit over Java, C# or Go is really negligible. Who needs more than 300000 req/s and can't afford servers to scale?
So, another nice try from the Rust evangelists, but no thanks.
> But why should one choose Rust when there're plenty of alternatives with much larger and much more stable ecosystems.
In my experience, and this is just a data point: because it is much simpler to write correct Rust code and to refactor large Rust code bases correctly than doing the same for Javascript, Ruby, Python, C++, C, Java, etc.
That Rust has great perf and uses little resources is just a bonus, but not something that most apps will care much about.
The downsides you mention about the ecosystem, libraries, frameworks, are real.
I disagree with your claim that there is no "talent pool" for Rust. The "talent pool" for javascript or C++ is _only_ "all javascript experts" or "all C++ experts" because if you are not very good at Javascript or C++, you can't really be trusted. A Javascript programmer can start being productive in Rust without issues quickly, but the same wouldn't be true if they had to program in C++ instead.
The "talent pool" for Rust is "all programmers with domain knowledge". If they are not experts in Rust, that doesn't matter. Smart people you want to hire all pick up Rust very quickly, and the amount of dangerous mistakes anyone can make by not being a Rust expert is very small.
Offer/demand wise, the demand for Rust jobs is much higher than the Rust jobs that are currently available. If you post a Rust job on reddit you'll get 100 CVs in a day...
---
IMO, your main point still holds: right now Rust web frameworks are not as feature full as Django, Rails, etc. and if Rust frameworks are missing features you need, picking it up for a professional project probably doesn't make sense. Unless... you are willing to implement those features yourself...
Why should we do anything new? I've been seeing this attitude more and more where developers think they're entitled to be convinced to use some new technology as though their time and attention are so valuable it's someone else's responsibility to convince them to spend it.
What I think differentiates this from normal outreach and education that every project needs to do to build a community is the sense of entitlement and the declaration that they're outright hostile and argumentative and then expect to be engaged.
From a management positions this is probably the most important question you can ask. Your most expensive resource is your programmers, and a few talented operations guys, and you need a good reason to expend those resources.
We work rather closely with other municipalities, and one in particular is very adoptive of new things. One of the things they adopted was kubernetes. But the thing is, we’re not Netflix, and kubernetes isn’t easy, and the result was they spend two years worth of man hours on something that didn’t make them anymore competitive than us because the advantages never really comes into play in our small enterprise organisations.
We spent those two years worth of manhours improving our Azure strategy, getting our operations guys up to speed on powershell and our developers on python, and actually moved our organisation forward in a manner that was useful.
Maybe Rust is useful, maybe it’s going to have a brighter web-future than .Net Core, but if you can’t show me how that is, or why I should adopt it, then it’s a really big risk that I’m happy to let other people take. We can always adopt it later.
Of course you probably meant to ask the question in a different light, and I think that point is very valid. I just can’t stress enough, how little something being all the hype actually means. What if Rust turns out to be another Ruby on Rails or “Node.JS for everything” craze? Then I won’t lose any sleep over never having thouched it, and if you look at our local job market, then there hasn’t been a single Rust focused job in my entire country for two years now. Not even as a “nice if also you know” listing. That doesn’t exactly install me with confidence that Rust is ever going to be important.
You're in a position right now where you probably ought to continue using Python. It's a great tool for many jobs, the community is super helpful and very capable, and the ecosystem is tremendous. Tech decisions are hard to make and managers try to choose carefully. It sounds like your team already bought into some of the costly hype by adopting Kubernetes (and probably microservices). It takes restraint not to go further and rewrite everything in Rust.
It's been a while since microservices became a big deal, so the tech industry may be due for a cost-cutting correction where projects consolidate a constellation of microservices to efficient monolithic systems written in systems languages such as Rust or Go and use leaner hosting solutions. You can adopt Rust then, maybe.
Seems like a natural defensive mechanism against the hype train, which is real and various industries make their living from churn. Because of the bias of vested interests many new things that are pushed are not really in the developers interest. Some are, and some are worth the effort, but many aren't and how do you know which without expending your limited resource of attention?
I think a problem exists when that something new is being pushed and hyped in order to create a self-fulfilling prophecy where everybody starts jumping on the bandwagon and an ecosystem is built.
Many people use Node.js and Javascript because they get to use one language on both server and web browser. Rust can probably do the same in future. Rust on server, Rust with WASM on web browsers and then Rust for local software.
Right, so you're saying we can take rust web backend seriously once Rust is popular in front ends? Cool, I agree, but that's just never going to happen.
C++ is not a good fit for network accessible services. It is too easy (even with Modern C++) to cause memory based security problems (and I say this as someone who writes protocol stacks in C and C++ for a living).
Rust's security story is much better out of the box.
Not sure of your protocol stacks but I happen to write network accessible services in modern C++ for living as well. Without going into much details I'd say that I do not really share your point of view. Not sure when was the last time I had any memory related problem with modern C++.
Actix-web makes some very aggressive use of unsafe. Many core Rust libraries do too. If you trust those authors (some very fresh out of school) to have zero mistakes, why would you not trust the C++ STL?
I am less worried about libraries than I am about usage of them.
I don't have personal knowledge of the use of unsafe in Actix-web, but yes I agree that it's not ideal and I would prefer to use an alternative. On the other hand, it is a library used by a number of projects and so security problems are more likely to be surfaced (and I get fixes for them for very little effort).
I'm more concerned with how easy it is to create security holes in your application (when built in a way encouraged by the framework), and it is definitely easier in C++ than Rust.
Occurrences of unsafe in:
Actix-web: 39
A few dependencies
Regex: 136
Bytes: 118
Tinyvec: 8
That’s far from exhaustive. So I wouldn’t consider this implicitly safer than any particular C++ library that has been through some basic static analysis. If anything, there probably have been way more eyes on STL. I would be even less confident in this case since the author of Actix who probably actually knew what he was doing was harassed out of his own project by the friendly community.
I get the safety for performance trade off, but Rust evangelists pretend this trade off never happens, and it’s very pervasive in important libraries.
I would call dozens of uses in the core and hundreds in the dependencies aggressive usage. Statically determinant memory use is the main reason we’re not taking advantage of decades of C++ development, after all.
But why should one choose Rust when there're plenty of alternatives with much larger and much more stable ecosystems. And those alternatives offer much higher productivity and a much larger talent pool.
Rust is not even the fastest web framework (https://www.techempower.com/benchmarks/) . And the benefit over Java, C# or Go is really negligible. Who needs more than 300000 req/s and can't afford servers to scale?
So, another nice try from the Rust evangelists, but no thanks.