I was just reading slashdot's crowd discussing this article:
I could not helping noticing that many who commented there had totally wrong ideas about Rust. For example that it had garbage collection, that it offered no new, distinguishing, features. And so on.
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.
Great idea. Only problem is that prolonged exposure to slashdot causes one to totally lose faith in humanity and descend into a suicidal depression.
I guess that answers my own question really.
Anyway, I guess it's best not to evangelize Rust. People have an amazing talent for putting up resistance to an idea in proportion to how hard you try to sell it to them.
I'll just keep Rusting quietly and perhaps set an example others may get curious about.
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.
C an C++ are from a different generation. There is so much competition for a programmer's attention these days, and myriad languages seem to flicker in and out of existence at the speed of light. Why do people use Javascript on a server? Because of Node. Very few people would ever consider implementing this from scratch. There is nothing about the language that would suggest it is optimized for that purpose, but because Node exists already, people do it. The smaller libraries in an ecosystem tend to feed off these larger frameworks.
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.
I have to disagree there. There are indeed fundamental features of Javascript, the language itself, that motivated it's use on the server and the creation of node.js.
At first sight the suggestion to use that silly scripting language Javascript on the server seems crazy. But Ryan Dahl had very good reason to come up with that very idea and create node.js. Namely conservation of resources and performance when building servers that are to handle many thousands of connections simultaneously.
It's all about the event driven model of programming that pervades the very definition of the Javascript language and it's APIs. That makes it efficient to asynchronously handle thousands of connections and other processes without the overheads of threads. That is to say "async" programming, which I have noticed has been a big concern of Rust recently.
Not only that but Javascript is a thousand times easier to use when doing this kind of thing than say C++.
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.
I have never thought of node.js as a "framework", rather a run time for Javascript, same like the Python interpreter or Perl or whatever. I might accept that the express module I use to help with HTTP stuff is a "framework".
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.
Where does "frameworks" fit in all this? Well the Express web framework in node.js maps to Rocket or actix-web or whatever.
As such the Rust world already provides all the comforts of JS/node.js, even if there is not the millions of crates for Rust as node has modules.
In fact in our switch to Rust from node.js I have yet to find a missing component, from serial ports and GPIO on embedded devices to web serving, web sockets, database connectivity in the cloud.
I think JavaScript engines like V8 or Chakra are more appropriate comparisons to rustc. NodeJS is a runtime like Tokio or async-std. It provides an event loop like the rust counterparts along with providing access to files and other system resources which were previously not available to JS when it ran only in the browser, another JS runtime.
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.
). 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).
