The community lives in a bubble and is out of touch with mainstream software development.
The industry has needed good alternatives for a long time. Finally, they're coming, and not nearly soon enough to suit me! :-)
I consider Rust more pragmatic at this point. Perhaps it's because I code in C++ as my dayjob and have to deal with the consequences.
In theory, C++ is perfect given perfect developers. In practice, it's more sensible and realistic to write tricky, like multithreaded, code in Rust.
One rarely mentioned important factor: fear. It's much less scary to modify something written in Rust than in C++. Doubly so for less experienced developers.
Rust, culturally, comes from the web. That's why it has the most traction in the web server/WASM space for now. It's starting to poke its head into Systems use-cases because of the sheer weight of its memory safety benefits there. Maybe in a few years it'll get some real use in the games industry (real industry; not just enthusiasts), though Unreal remains a bastion of C++ that isn't going anywhere anytime soon. But then there are some dark corners of C/C++'s territory that move even more slowly, and where the cultural shift will take a long time. I think to a great extent, embedded falls into that category.
WASM as a target is actually a great indication that it's a system language -- performance is a primary consideration.
Which is very different than "web people", which in my mind implies webdev -- html/css/js + API server/db/caching backend.
Which also further explains why WASM is so far along (sandbox, security), much better than any association with webdev itself; but not kernel-level system development. (But if the web browser is an userspace OS... then it's probably not that far from it)
Few "want" C++, but for robotics a non garbage-collected language is necessary so latency is predictable. There are few mature languages besides C/C++ in that category.
Rust is an improvement, but I'm hopeful something like Julia (Julia Robotics, https://juliarobotics.org/) or Scala Native (https://scala-native.readthedocs.io/en/v0.3.9-docs/) becomes mainstream, the productivity gains would be substantial.
But perceived "comfort" isn't entirely reality. (The comfort of smart GC languages is immense in a different way.)
For 99% of realtime work, the Rust or Scala Native approach is just fine. No GC required. Julia users can just use the pre-allocation approach.
The important thing is avoiding language patterns that encourage needless allocation.
GC languages still support stack allocation, you don't have to pre-allocate anything you can stack allocate. (That's where .NET Core has been especially burning rubber in recent releases. Span<T> is a stack allocated, GC-safe "pointer", for instance, that is doing all sorts of heavy lifting in .NET Core performance-critical work these days. It's still early too, as not everything has moved to Span<T> that can move to Span<T> and family.)
But also, not everything needs to be pre-allocated for the "best approach". There's some work to get used to the feel of any specific GC, but most modern "VM" GCs (.NET and today's Java, not yesterday's) are multi-generational and there's a lot you can do in strategies such as "focus on the nursery and the LOH" (using only [potentially many] small short-lived objects and a few, mostly stable "very large" objects, avoiding the intermediate generations).
> why carry the overhead of the GC at all?
Safety. (Why wear seatbelts?) Rust's borrow checker is great but it still requires a lot of manual adjustment and it's still possible to miss something (it's not easy, certainly, but it is possible); a GC gives you safety by default, with no manual intervention required to guarantee safety, and requires manual effort to write unsafe code.
> The important thing is avoiding language patterns that encourage needless allocation.
That's where we agree and why I'm very adamant that though some of the tools ("knobs") look scarily different in performance optimization for GC versus non-GC languages, the vast majority of the tools are the same: know the O(memory) of your algorithms, and make smart trade-offs regarding that O(memory), avoid allocating what you don't need, know your trade-offs between pre-allocation and allocation only when necessary, etc.
Could you elaborate?
It is a great choice to prototype the ideas
Previously, the code base was primarily Python with some C++. Now there is a significant chunk of code, particularly related to safety, written in Rust.
Firstly, because 75% of all that knowledge is easily transferrable.
Secondly, because you want to take 50% of your bug count.
It doesn’t work well for embedded programming.
It very much does not fix all bugs, especially given lack of static type checking.
I actually worked in Automotive, and the software higher level up the stack there is usually god damn awful piece of s*, often done by people who have almost no clue what they are doing, with plenty of misconceptions about how C/C++ even really works (using `volatile` for concurrency/atomicity and stuff like that). They are just beating their spaghetti code from segfault to segfault for decades.
This and slow delivery process easily explains why entertainment, navigation and other software-driven part of mainstream cars are so buggy, slow and generally terrible, and why Tesla could have so easily deliver way better experience.
So it doesn't matter that some people can't "get into Rust". The business that hire them will be replaced if they can't up their game, that's all.
Building ecosystem just takes time.
C++11 is a really good language. Also there are tons of libraries and things people have already built in it that you can leverage to reduce development time.