The second worst thing is how difficult to use it is which makes it not worth it for problems where you can use a higher-level garbage-collected language.
The second worst thing is how difficult to use it is which makes it not worth it for problems where you can use a higher-level garbage-collected language.
I always find it ironic that people say that Rust can't handle criticism when it is constantly being criticized... like in literally this exact post that we're all commenting on. That is a happy Rust user criticizing the language lol but yeah sure "many fans" refuse to listen to criticism.
There, this was your mistake. :p
That and some of the projects and types of work adopting it; last year the "web3" and "crypto" companies began piling in, which had a markedly corrosive effect on the language and its emphasis. In general, the amount of "webscale" type work being done in Rust right now has shifted the focus in published crates, etc. from "systems" type work to a lot of the "async serving" types of stuff. For someone like myself whose interest (and day job) in Rust is in embedded, "systems" (closer to the metal, storage, virtual machine, database internals, etc), and the like, this is a bit discouraging. In general the list of speakers at RustCon (before the whole fiasco) didn't look on the whole like the list of speakers around a "systems programming language" for example (with some exceptions).
As more "boring" work is done in Rust, this will hopefully shift. The trend hoppers will move on.
This had nothing to do with web3 and crypto, and everything to do with FAANGs and similar large companies not in those industries.
But there's job postings all over the place for either "web3" companies and/or others for tokio/async/web stuff in Rust. Which seems like gratuitous novelty seeking to me, TBH.
* Netflix isn't using it at all, as far as I know
* Google is using it in Fuchsia and Android, but I'm not aware of many web service things. Fucsia does use async/await though. Not sure about Android as I haven't examined it closely.
* Apple is using it as the backend of services, and on some storage team, though for the latter I haven't heard from it in a while. They're absolutely async/await users.
* Facebook/Meta are using it in a number of ways, for services but also as well as like, the SCM, filesystem, and build system. The latter aren't web services but do use async/await.
* Amazon is using it heavily inside of AWS. You don't get more "web services" than that.
But also, I meant "FAANG" in a broader sense. Large, established tech companies. Cloudflare, Microsoft, stuff like that. If you check out who is sponsoring the Rust foundation (not that that means that this gets you more weight for new features, mind you) https://foundation.rust-lang.org/members/ it's very much not dominated by crypto or web3.
When I was on the Rust team, we didn't prioritize web3/crypto use cases, and I haven't seen any evidence of that changing. It's always been kinda awkward, frankly.
After writing this comment, I also wonder if maybe that's also not some of the disconnect here: while async/await is critical for network services in Rust, it's also useful for other things too. So you have a larger coalition than you may think that's interested in directing the language in that way.
FWIW I worked in ad serving for some years (at Google and prior) and much of that work is done in C++ because of millisecond granularity P99, etc. latency concerns. Rust is a natural fit there, even though that is nominally "web serving"; but that's a different domain than serving up database-backed microservices for typical web customer workloads; that stuff is on the whole I/O blocked and not impacted by GC sweeps.
That is not a bad sing, in fact.
That mean the app was write and now is the second(third...) time.
I do this, for work. People pay me to make this stuff several times in the past. And moving langs and other major changes (like move from web to mobile).
Rust make this much better than before: You get some fast, yeah, some safety, great, but much better modeling of logic and great tooling, even errors are much better here! (ie more detailed, better resolutions).
---
Rewriting a system is assumed to be a terrible mistake, and that is true mostly for organizational or political reason, but is VERY profitable if done by technical reasons!
To make it a failure:
- You need something dysfunctional in the org/team, and stay or move anyway will lead to doom. Make the jump to Rust WILL make this more evident!
- You have inexperienced people doing this. Stay or move anyway will lead to doom, but move will be faster!
To make it a success:
- You somehow have a decent org/team
- Budget the time required to make the change, not do it with major time presures
- Do some small test validations, maybe just experiment a little a few weeks/months if the app is truly big.
- Make the jump and use real data ASAP
The rest is obvious work...