I would be interested to know if this is really the official opinion of Microsoft, or if someone just wants to make a name for himself.
You mentioned Ada, which does have a minimal runtime. It might be interesting if the community and ecosystem made a strong push into general-purpose programming, like rust has. I would give it another try.
Rust seems to handle heap allocations more fluidly (or at least closer to what I expect), but perhaps that wouldn't be a deal-breaker if I knew more about progamming in Ada. Rust also has better C integration -- it can match C structure layouts and operate on them seamlessly with rust semantics. But basically, it seems plausible that Ada could work with the right ecosystem around it.
Regardless, Ada has had decades to make the leap into general-purpose programming, and it hasn't done so yet. Rust is viable today for a lot of important use cases, and is not far off for a lot of others.
Swift, Zig, Rust, Go, etc. are popular because there has been a resurgence of new languages in recent years and a lot of new, young developers are helping develop libraries for them.
It is simply not as fashionable to program in old languages so some new developers don’t.
If moving away from C/C++ to something, C and C++ are out of the running. You can claim that they should still be considered, but they've been around a long time and people have tried very hard to make them safer. There's been some success, but there's not a lot of evidence that real C/C++ codebases will become dramatically safer in the next 5 years. It looks like some people are looking pretty hard at alternatives.
Ada and fortran are both older than C++, so it is not clear that there ever was or ever will be a lot of net movement from C++ to either of those unless something exciting happens. It would be cool if Ada did get more appealing for C++ migrations, but I just don't see it happening.
That leaves D and Rust. Apparently a lot of people think rust has the mix of excitement, community, and technology to make it happen. We don't know for sure, but it seems like a reasonable bet to make if you are trying to dislodge C++ due to frustrations about memory safety.
Apparently, the author thinks that rust might make that leap sooner than Ada/C++. It seems like a reasonable guess, and with some backing by major players, it might well happen.
Sure, there's a lot of uncertainty while we are waiting to see the results from a diverse set of large projects. I have used rust enough to be annoyed by it, but none of the annoyances seemed like a major blocker to rust's future.
What do you mean? Ada is used routinely in some industries.
Ada is a possibility, but it's just not there and does not show signs of being there soon. There's probably not a net movement from C++ to Ada today, and there is no reason to expect differently over the next 5 years.
Rust is not a sure bet either. Lack of major real systems is a big question mark. But basically the article's thesis makes sense to me.
In what sort of polls is Rust's popularity overrepresented (when compared to industry usage)? A lot of people on Internet forums like Rust, but a lot of people on Internet forums like a lot of languages, especially new ones.
And what is your definition of "hardly ever used"? I can think of plenty of programs I use frequently that make use of Rust (e.g. Firefox). Compare the use of Rust to, for example, Racket or Haskell or Julia (all fine language). I've definitely interacted with programs written in Rust far more than any of those three languages. So at least Rust is seeing some niche usage.
Not trying to come to Rust's defense, just trying to understand this point.
Only a small fraction of "Rust fans" are actually using it.
* The claims aren't baseless. We've seen for decades already that memory safe languages have fewer memory safety issues than languages that are not memory safe.
* Asking for hard proof is silly in software. There's tons of research into programming languages and their impact on software projects, across a number of areas, and it's all fairly useless - it's extremely expensive to do right, and impossible to objectively measure.
Common sense isn't propaganda.
That's what I would assume ;-)
By the end of the day it's also a question of performance. For embedded, realtime or mobile core technologies there will always be a need to shortcut.
> Asking for hard proof is silly in software.
Not only in software. That's what the scientific method is for. That needs time. Currently there is a debate whether the switch from Ada to C++ for the F-35 is the cause of all the observed problems and budget overruns. There is still not enough data to know. But there was a decade-long track record for Ada in avionics. And C++ also had to establish itself for twenty years before anyone dared to develop an F-35 with it.
You can however prove that the language solves a particular attack ;)
> And just as one can write secure code in C++, it will turn out in time that even with Rust not everything is as secure as propaganda would have you believe.
I think the point is more that Rust is memory safe by default, and you have to opt out of it. In C++ on the other hand, memory safety basically falls to the developer, with plenty of crazy pitfalls to watch out for in the language. It's not that it can't be done, it's just harder to do it right. Rust makes the easy, default thing safe, and the unsafe thing requires extra effort.
Yes, unfortunately; the trend seems to go in the opposite direction; but anyway: if I really wanted to switch to something new and spend the effort to invest in new tools and education, then I would rather choose a technology with a decently long track record demonstrating that it fulfills all my expectations because of which I left my original technology. Rust will take one or two decades for this; Ada/Spark has already been through this.
What I hate is rust fanboys' propaganda that rust is great for every purpose including CRUD stuff because crab god moral and borrow checker is moral responsibility. There is lot of dishonest marketing sounding like rust doesn't have cognitive overhead compared to other languages. It gives me an impression that, in best case, it is selection bias among people that successfully learn and use rust, or in worst case, some people trying to show off that they learned a 'hard' language and it is 'easy' for them.
Secondly rust community is very political and polarising that many people don't like. It almost seems full of non-STEM-worthy people although they are a vocal minority..
An example from a while back: needing to rewrite your whole original Ruby code base in Scala. Or having to write your own PHP compiler.
There is a similar phenomena around Microsoft, with nearly every news item about them attracting two such camps, so this news item happens to find itself at a rather unhappy intersection!
For what it's worth, as someone who's working on a first project in Rust right now, the actual Rust documentation and direct Rust community seem to be friendly and helpful. It's only in more 'neutral' discussion forums like here where most things about Rust devolve into trench warfare. I also feel that, subjectively, the core Rust communities (e.g. the rust-lang forums) are pretty honest about identifying places where Rust or its tooling currently fall short (plenty of "I don't know that there's a good way to do this right now.").
Source? The closest thing in C++ to what Rust offers today is the C++ Core Guidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines but these are best-effort in nature and do not have a goal of comprehensively ensuring soundness or memory-safety.
And I'm not sure why you're implyng that the Rust featureset "isn't even thought through" when the Rust Belt project has been doing a lot of work on modeling it in a principled and clearly-understandable way, and this has already contributed usefully to the design of newer Rust features.
I'll believe it when I see it. The C++ committee consistently fails to deliver on safety features.