Now it's Rust based on what? Uber backend is almost entirely built in Go. And so are many other services handling billion plus requests a day written in other languages.

Perhaps Rust advocates know something that Uber engineering does not.

I'm interested in why you made the choice to use Rust for a web app? It feels like you love a good challenge, but there are obviously technical constraints for some apps. I look around and wonder if the options have really changed a whole lot since 2006?

If you need productivity, choose Ruby or Python (or maybe JS.) Java and .NET exist if you have more exacting performance requirements (these platforms are somewhat more pleasant in 2019 and I see Go as joining their ranks.) Or, you choose to go really low-level with C/C++, or perhaps Rust in 2019. The latter never seemed like a viable option unless you had extreme performance concerns.

All browsers you use are written in C++ (Firefox, Chrome...). Node.js is written in C++.

We live in that bizarre world, where on one side we have C, an antiquated and simplistic language and on the other C++ a monster of complexity that provides also basic modern stuff C will never have.

Rust has complexity of its own but it's more like a "philosophical" complexity rather than syntactic. A lot of C and C++ developers just don't like how Rust works.

I'm a full time c++ developer that does Rust as a hobby, and I'm asking myself if we are talking about the same language. C++ is a clusterfuck of obscure features, 1 million different build systems and hacks upon hacks for even simple things like include guards, forward declaration of classes to not completely kill your build times and _many_ more daily struggles that are simply none existent in Rust.

Yes. The overwhelming majority of industry is using C/C++.

Rust is still very much niche when compared to the overall market.

Additionally, (Someone can correct me if this is wrong) IIRC, mozilla, was initially one of the biggest proponents of rust, but still just uses rust in a supplementary role. C++ still powers the heavy lifting.

This heuristic wouldn't work for my department because we build web backends in C++. I keep telling the most senior devs here that nobody does this and for good reasons (velocity etc), and their response is "who cares what the rest of the world does, they're just bad at C++."

I maintain a 180k+ line of code back-end web project and I use Rust. Best decision I've ever made.

I serve over half a millions of HTTPS requests per day. Everything hits the backend, no CDNs or caches of any kind. Average CPU usage on a cheap VPS? ~3%. Hugs of death? No such thing for me. It just runs itself without any supervision for months uninterrupted, so I can sleep at night and not get woken up by an outage. And refactoring is a breeze due to a strong type system, plus all other niceties that Rust has.

So for a complex project that you're going to maintain long-term? Rust is absolutely the right choice, even for backend web-dev. A throwaway CRUD e-commerce website made by a random webdev consulting company on the cheap? Okay, yeah, maybe here you're right, and I probably wouldn't pick Rust there either.

I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested.

A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs.

Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time. It ought to be used more for high-performance games, but the game infrastructure isn't there yet. Unreal Engine is C++ and Unity is C#. Rust has Bevy and Rend3, but they're not AAA title ready.

Perhaps Rust is fighting the last war - the mess inside C++.

I have to admit that I have limited experience working deeply with Rust, but I've found thus far that my relative productivity is inversely proportional to the size of the project. That is, for large projects, Rust is much more productive than other languages. For small ones, less productive.

Rust is just a language - and it's just as suitable to deep embedded and general system programming as it's ever been. The real difference is that it would be insane to write network services and especially web stuff in C/C++, whereas Rust makes this quite feasible. Why are you surprised that web folks are interested in doing that?

It will happen, but it's not something you should do today. The async ecosystem in Rust is not yet ready for prime time, there are key language and stdlib features that are just missing. And this in turn holds the web ecosystem back. If you write a web backend in Rust today, you might just do a lot of pointless work that you'll have to rewrite in the future anyway as more advanced frameworks come along and the earlier ones are practically abandoned.

Right now? Do you do any embedded development at all? In principle, I would love to ditch C++ in favor of Rust forever, but in practice Rust isn't anywhere near "there" yet in terms of tooling and platform support.

I'll say it. At work, the backend is Rails, and I am a Rust contributor in my freetime. I am in the early stages of working on a framework for web apps in Rust & I believe it will be comparatively productive to Rails. Only your code will be faster and many bugs will be caught at compile time.

If you’re building a large complex app that needs to be shared across multiple platforms, C++ is a common choice. Not talking about games here, think Office, Facebook, Zoom, WebEx etc. It easy to see Rust replacing C++ in that stack.

But as Rust is so much nicer that C++, I could see it becoming popular for smaller projects that want to share common logic, with a native UI on top.

I have replaced all my tooling with Rust, fwiw. Rewrote several things at work with Rust (which started this train for me lol), and now all my projects are in Rust as well.

I often say that Rusts complexity is oversold (by myself, too, at times), and it can be just as productive as Go, if used like Go. That is to say, Go is often touted as being hyper productive because it takes decisions away from you, such as Generics. You can apply the same tools to Rust, and suddenly you lack a ton of features but also reduce the possible roadblocks you might be wanting to avoid.

Personally I don't even avoid any Rust features these days, I use all of them (that I understand, at least lol.. which I think is all). I more productive than in my Go days (~5 years in Go, fwiw).

Erm, have you ever used Rust, and had much experience with C++? Rust's semantics are far clearer, simpler, and well defined than C++'s, and there are orders of magnitude less rules of thumb that you need to learn in order to avoid. If it looks complex, it's because it needs to be in order to adequately express the essential complexity of systems programming. Hopefully we will have languages that do a better and more elegant job in the future, but at the moment Rust is the best we have.

I have, and Python from 10 years ago was a better platform.

Sure, it beats the Javascript ecosystem, but that's too low a bar.

I tend to think unless perform/$ is really important one should use a managed language for that, that isn't Javascript.

But yeah, not really sure what some other language would buy me in the small embedded space that earns me my beer money. I recently had an issue where the corporate spyware was convinced make/gcc were up to no good resulting in minute and a half compile times instead of the usual 10 seconds. I spent a bunch of time with IT getting that fixed. Well that's the build time I'd get with Rust. So Rust is a big nope. C++ is not that slow but still slow. And C++ without malloc is well who are we trying to kid here.

I'd go with 1/3 less performance by using Java or C#. While having better productivity. If we are talking a web service, of course.