At the end the day it's platforms that move languages, not posting on HN and reddit.
They quite brutally damned Rust with faint praise in the article: "It’s also worth noting that even if Rust never gets much beyond where it is today, it’s still ranking higher than well known languages such as the aforementioned Clojure and Groovy, as well as CoffeeScript, Dart or Visual Basic. Not bad for a systems language."
Ranking higher than VB...
MS basically killed it, in 200x when the VB.NET snafu happened. I assume 100% of the VB work is legacy at this point and since solid architecture or design principles were never this language's strong points, it can't be particularly exciting legacy work either.
It's basically a career and technological dead-end.
While it may not be exciting work, not every programmer is looking to do the latest and greatest thing that will appear at the top of HN. They make good money because the business knows paying someone well to maintain it is better that paying a team to rewrite it. That's why one of the issues with COBAL programmers is retiring and passing on, not leaving to go to a NodeJS shop.
On Windows C++ was the tool of choice and Delphi was kind of a secret weapon for GUI development. Then C# happened, and MS unceremoniously flushed VB down the drain. The VB community was outraged about VB.NET...
So, I'm curious: how does HN see this situation going forward? Where will Rust find widespread industry adoption, and what can Rust community do to bring this forward?
Rust can best grow its developer base by growing the number of new systems programmers, as they would have less to lose by using Rust and would be less likely to notice its limitations. The challenge here is that becoming a competent systems programmer is much more difficult than learning a new programming language, and there is a chronic shortage of developers interested in systems programming.
If we were still using classic C++ (i.e. C++03 and earlier) then I think Rust would have a real chance. The rapid evolution and adoption of modern C++ has fixed many (most?) of its major weaknesses.
Majority goes to Rust for what it is developed for: system programming.
Just like I won't use Go for web app dev (ugh.. what a PITA)
Modern C++ is not memory safe, and there is no way for it to achieve memory safety without either significant runtime overhead or breaking compatibility so much it won't be C++ anymore. The features in modern C++ are nice, but they don't solve my problems.
Perhaps the driving force demanding memory safety isn't for one's own use, but rather the hope that the code one depends upon, written by other people, will get better. I.e., I write good code, and you write good code, but God forbid we have to rely on Microsoft, Google, Mozilla, and Red Hat monkeys to write good code! That's a legitimate desire, but it doesn't drive much personal adoption. Meanwhile, the PITA factor -- borrow checker not happy! "&" required! "&" forbidden! -- interferes with personal adoption of Rust.
And C++ keeps adding features. Not to fall increasingly behind, Rust needs to multiply its adoption rate. I don't see how that could happen. C++ is already good enough, so Rust can't cannibalize significantly from C++ coders. Rust is enough better than Go, Java, and C# to be worth a significant effort to switch, if users of those languages could perceive it. The greatest benefit to the world derives from driving people off C -- to Rust or modern C++, it matters little which.
I would use Rust in place of C++ or C in a heartbeat (and I would probably pick it over Go until they have generics), but I wouldn't use it in place of those other languages for the same reason I wouldn't use C++ in place of them. They're already managed, and I wouldn't have used them in the first place if I needed Rust's performance.
That's easy to answer. They do. Any look at a CVE list for a browser will confirm this. These browser engines are, by and large, written in a modern style.
> Are they now of mainly theoretical importance?
No.
At the same time, modern C++ also has advanced and valuable safety features that Rust does not have e.g. the enormous amount of compile-time verification and complex type construction that is possible. I find these to be far more valuable because the kind of bugs these catch are more common in practice. None of this is automatic but it is trivially enforceable as coding style, and many companies do.
The idea that C++ code bases are necessarily littered with memory safety bugs is nonsense. For people that have been writing this kind of code for a long time, avoiding those bugs is largely automatic and effortless. And you don't have to do violence to your data structures to achieve it. I can see an argument for someone coming into C++ from a language like Java but for experienced C++ programmers the value is dubious in practice.
There may be compelling technical reasons to use Rust over modern C++ but you'll have to do better than automatic memory safety, particularly given the safety and capabilities that would be sacrificed.
(I also disagree that modern C++ is safer than classic C++. Modern C++ adds more invisible ways to get use-after-free, which is pernicious.)
Some bigger companies are supposedly using Rust (Amazon, Google, MS) on some projects, but these companies have so many things going that they are likely to use most languages in some kind of project. I've also heard that there are several "invisible" Rust jobs, only available through connections - but these are irrelevant IMO. And then there are the jobs where one is obviously not using Rust, but they mention it to score points or dangle it as a possibility.
Until I see a strong market for Rust skills, or my own employer offers interesting Rust projects, it doesn't make sense for me to invest beyond learning the basics. Funnily enough I'm looking into Go now - its job market is one-sided and quite anaemic, but it offers some nice technical benefits and is a piece of cake to learn.
Show them to create a secure COM component to integrate in .NET can be easier than writing it in C++/WinRT | C++/CLI, using the same VS/debugger integration while being safer, for example.
Repeating ad infinitum in every HN thread about C++ improvements regarding safety, that the only path to enlightenment is rewriting the world from scratch, without any regard for the loss of productivity, tooling and libraries in doing so, always hand waving them as minor inconveniences, is trying to catch flies with vinegar, but I guess I am wasting my Latin as we say back home.
I've said many times there is a legitimate reason to write C++. If you understand you will be shipping memory safety issues, but the advantages of C++ outweigh the memory safety issues that you will ship to production, then I can't argue with that. I've seen game developers argue as much, and that's legitimate! Maybe, for your use case, memory safety problems really don't matter (or don't matter enough to outweigh C++'s other features). But it doesn't do anyone any good to sugarcoat the fact that C++ at scale virtually always ends up with memory safety problems, and while there have been many mitigations there has been no effective solution so far.
Maybe it will change after the HoloLens/FF project, however today is not appealing to many Windows teams.
Having said that, I don't think the rust ecosystem is going to go up in flames anytime soon, but lack of professional application at the moment doesn't bother me too much.
Most mainstream languages being used today took around 20+ years to get here, Rust will need as much for long term survival.
It did? Can you link me to the new stuff?
After a lot of languages that are just rehashes of what we’ve already seen, or just a different subset of features, Rust is a languages that actually feels like it’s from the future that's finally going to start moving us forward after a lot of stagnation in industry while PL theory has continued to move forward.
If you haven’t given Rust a shot yet now is the time. You can get rust up into the top ten. :}