Honestly, programming languages are complicated, and most people overestimated how well they understand them (including myself sometimes ). I don't think Rust is particularly unique in how misunderstood it is. In particular, before we even get to users of other languages, I think "Rust users who wildly misunderstand Rust" are way less common than "C++ users who wildly misunderstand C++" (for example, the leakpocalypse discussion was riddled with claims that C++ guarantees destructors get called in cases that Rust does not, which were all simply untrue).
That doesn't mean we shouldn't keep trying to get the right messaging out there, but we should avoid making the perfect the enemy of the good and accept that we're never going to make everyone happy when most of "everyone" is (understandably) not willing to spend months acquiring a deep understanding of Rust.
Also, to be less of a Rust fanboy for a moment, it is true that Rust remains woefully incomplete in some areas. In particular, const generics and inline asm are examples of features that will unlock entire problem domains once they're stabilized, but for now Rust simply isn't an option in those spaces. There are also many spaces where the library ecosystem trumps all other concerns. And some C/C++ code is possible but not super nice to rewrite in Rust without placement or specialization or GATs or Polonius or whatever else we're still working on.
But I'm summarizing my own anecdata here. My echo chamber is likely missing a few things.
You might consider browsing threads on Slashdot discussing other topics, and analyze whether there are a similar number of wrong ideas and misconceptions there. Depending on the result of that analysis, it may color your conclusion differently.
To the original article, I felt it was a bit clickbaity and didn't really have anything substantial to it that merited the subtitle "Developers reveal why more people aren't using [Rust]". Basically the article just says Rust has an adoption problem because people aren't using it. Which is frankly the definition of "adoption problem". (Which is not an observation original to me, but I don't remember where I read it first.)
Every thread about Rust on the broader Internet (i.e. not in Rust-specific channels) seems to attract some very uninformed people who spread memes like "Rust has horrible syntax" and "Rust devs are feminazis" on top of blatant falsehoods like "Rust has a garbage collector". But this is a lot like the people who chime in on Python threads with gems like "semantic whitespace is stupid" and "Python 3 is not Turing complete". And Python is one of the most popular and most used languages ever! So I don't think "getting the word out" is Rust's problem (if it has one).
To the average user, semantic whitespace / ASI is approximately as "stupid" as requiring semicolons at the end of every statement. They both generate tons of "compiler says NO even though it obviously knows what I wanted" moments.
I think adoption is largely driven by the "killer app." For a lot of people, their first introduction to Elixir was Phoenix, or their first introduction to Ruby was Rails. All languages have shortcomings, but people will overlook them when they see what is possible. There is no better advertisement for a language than when you build a framework and the entire community rallies behind it.
Interesting thought. I have never heard of Elixir or Phoenix and never seen any one using Ruby and/or Rails. I guess the closest I have ever come to using a "framework" is Qt in C++.
C and C++ don't have such a killer framework. Well, unless one counts the OS like Unix/Linux and many others as frameworks, but then C/C++ have been the go to languages when you have no such OS/framework.
In my mind Cargo and all the useful crates available are my framework for Rust already.
FWIW, I definitely think OSs count. Why would someone learn Swift, for example? The same reason they would have learned Objective-C a few years ago. macOS drives nearly 100% of that adoption.
The more skilled and experienced a programmer is, the less the killer app seems necessary, but there is a whole arm of language adoption that consists of people choosing to start their journey with a particular language, where the existence of the right boilerplate + community can make or break someone new.
As it happens I adopted node.js when it was very new, not because everyone else was using it but because it solved that server side problem very nicely. I discovered node.js made it possible to create our server side handling of real time data streams much more easily than C++ and almost match C++ in performance. Everyone around thought I was nuts but it worked very well.
As it also happens this last year I have been implementing similar real-time stream handling in Rust instead. Why? Because I found that what with the nature of the Rust language, the cargo system, and the crates available, I could create such things almost as easily as node.js but with significant gains in performance and confidence in it's robustness.
That is all the "killer app" for Rust I need.
Once again, everyone around thinks I'm nuts and just using the next shiny language. Although I like to think my choice of language and such is motivated by the technical benefits of performance and robustness.
I don't think you're nuts. Rust is amazing. But it also sounds like you have a fair amount of experience under your belt at this point. I think for the less experienced, having a framework like Node makes all the difference. At the time that you chose Node, would you have been just as likely to write your server-side code in JS if Node didn't exist? It's great that you're at a point where rolling your own application structure and conventions doesn't intimidate you, but if the goal is widespread adoption of Rust, I think these things make a difference. Since the universe of programmers has a disproportionate number of inexperienced participants, it's very difficult to grow a language that only appeals to advanced users.
If node.js is a framework, then so is Rust with it's Cargo and crates system.
As it happens, node.js did not exist when we started the project I was talking about. All our server side data streaming stuff was written in C++. At some point new features were required, I experimented with the new fangled node thing, quickly realized it was a much quicker way to develop what we wanted and performance would be pretty good. Slowly node replaced our C++.
When we demoed the thing at an expo I was looked at sideways. Apart from node.js we had used websockets and webgl, both of which were very new and only available under feature flags in chrome. How soon they became common place.
I would not call myself an advanced user of anything server side or web related. My history is mostly embedded systems.
Yes, of course you're correct. Node itself isn't a framework, but its existence facilitates a number of frameworks that make it easy for the uninitiated to begin writing server-side code in JS. There are so many amazing languages coming out (think Pony or Idris). What are they missing? It's the infrastructure around the language. All the libraries, frameworks, and tooling. It's normal for newer languages not to have these things. After all, the language must come first. And Rust is already much further along than many languages in this respect. But the more you build, the easier it will be for people to transition away from ecosystems where the language pales in comparison, but the ecosystem is more robust/established.
Well yes, my mapping is a bit fluffy. Has to be considering we are comparing a compiled language to an interpreted one. And the whole async/event driven thing is a muddle.
An out of the box run time for JS has to have an event loop. The whole language and it's API's are predicated on asynchronous, even driven operation. After all the language was designed to handle mouse clicks and the like without blocking and hanging up the web page.
This is not true of Rust. None of my Rust programs have an event loo.