This is a really useful description of current affairs. I run a bi-weekly Rust Hack & Learn for over a year now and am member of the rust-community team. After all this time “find an easy description of Rust that tells people why it is cool in 5 minutes”, I’d describe this as the hardest problem in Rust.
I believe that problem stems from the fact that many of the features of Rust (safe sharing of mutable and immutable data) click rather late and are rather boring in short example. Most of these relate to the borrow management and the whole ownership system. The great thing about them is that they scale really well to large codebases and enable a lot of guarantees, especially in the face of concurrency. But that’s something for people that are 3 weeks in. Before that, Rust is a fancy new C dialect with iterators :).
My biggest problem learning Rust isn’t it’s “cool factor” (I already think it is), it’s that the interesting projects I’ve come up with that Rust might be a good fit for are scarily big (ex: Writing a Unikernel, Building the storage layer for a database, Game Engine/ECS stuff). I think that’s partially because Rust’s benefits are evident for large codebases, so my mind goes there. More than “why is Rust cool”, I need to find a project that doesn’t overlap with my typical usage of other languages like Haskell (mostly web services)… or I need to figure out how to break down one of the bigger ones like a unikernel. /shrug
On the other hand, after writing this comment, maybe I should just get over my “fear of a large project” in a domain I’m unfamiliar with.
i’ve bounced off rust several times because every time i think i’ll start a project in it, and start reading docs, it always ends up being “oh, this is both easier and more concise in ocaml”. i think i just don’t write the sort of programs rust is best suited for.
i think i just don’t write the sort of programs rust is best suited for.
I feel exactly the same way. Also applies to Erlang, where you’d be nuts to use anything else for writing a cluster of non-HTTP network servers, but I can nearly always find an off-the-shelf solution for that kind of problem instead of writing my own.
I can totally feel that. Rust has interesting limitations, but it grows on you over a few months. I really don’t want to code in a another language for the time being.
Also, the language does not care so much about being concise, but I also don’t care about conciseness too much. (that used to be worse)
That said though, that’s probably true for many languages and not a feature of Rust.
I there any reason why you wouldn’t just write a component to a larger system, e.g. the rumprun unikernel (which is a supported target for Rust).
For contributing to an existing project, I’m more motivated to contribute to MirageOS or HaLVM which unfortunately doesn’t help my Rust interests.
The Mirage project has interest in Rust support but no one to take point. Two birds, one stone.
That looks great :) Thanks for digging that up!
What about a rust backend for GHC?
rustc is already a frontend to LLVM – doesn’t Haskell have an LLVM backend?
GHC does as of 7, and I believe it was improved in 8 (although I haven’t checked in on it)
I recently saw a talk about implementing an TLS library in Rust in a way that the type system guarantees resistance to timing attacks.
I thought that was cool, but I don’t know how much that will help you.
Could you find a link to it? That sounds super cool!
I don’t think the talk was recorded, and I don’t know if the slides are up, but the paper can be found here.
That is very cool. If I end up going the Rust Unikernel route, I’ll build a TLS stack anyway. Mirage built their own, but afaik it isn’t resistant to timing attacks (and opens up an attack via GC).
not sure “guys, great news it’s not us, it’s our adopters' misunderstanding” is a particularly powerful analysis.
That’s a pretty pessimistic reading of the blog post. Discovering the users expectations and shaping the perception of the language correctly is a huge challenge.
It’s much less of a “guys, great news it’s not us, it’s our adopters' misunderstanding”, and more of a “oh crap, people are trying out rust with a mindset that might not be productive or encouraging.”
The author admits that correcting the expectation is a much harder problem than acknowledging that there is a problem, but it’s a good first step.
“oh crap, people are trying out rust with a mindset that might not be productive or encouraging" is merely and exactly rhetorical dressing on the fault laying with the users. Maybe I made that too barefaced for your liking, but the OP rubbed me the wrong way.
The author doesn’t assign fault to anyone but does say “how can we fix this?”
The question is how to correct expectation. I really have no idea, but maybe explicitly talking about the problem will help.
I don’t think the author was saying “great news, it’s not us; we don’t have to improve ourselves”. I think he was saying “I’ve identified the problem, and it’s ‘how can we improve our communication to C++ users?’” It is totally possible to answer that question, rather than giving up and blaming the users.
One obvious way to mitigate this problem is to change parts of the Rust documentation or home page. Another, unlikely, way would be to change the syntax of Rust to something less C-like so C++ developers don’t think it looks easy to learn. It’s interesting that this perception is a problem, given that I think the syntax was made C-like to drive adoption in the first place.
There’s been talk in the Rust community before about where people are coming to Rust from. Each group “gets” different parts of Rust right away, and each group has their own confusions about and desires for Rust. (Warning: lots of generalization coming.)
People coming from statically-typed C-family languages like C, C++, and Java are usually enticed by Rust’s promise of performance and scalability. People coming from each of these languages have their own problems, but it’s this group that has the “why can’t I make a linked list?” response to Rust. Note that they are (usually) quick to grok ownership and borrowing.
People coming from functional languages like Lisp, OCaml, and Haskell are often enticed by Rust’s type system (which is very similar to Haskell’s), its pattern matching, and its bevy of functional-style interfaces. This is the group that asks when higher-kinded types are coming to the language, and generally pushes for expansion of the Rust type system so it can encode more (and therefore check more) about Rust programs. They generally have the hardest time with ownership and borrowing, as the languages they’re coming from usually just box up everything.
Anyway, sometimes I think it would be worthwhile to create three separate introductory “tracks” for Rust, one for each group, to both highlight the things that the group is most likely to appreciate, and to spend the most time on the parts of Rust most likely to give people in that group trouble. In the end each track would cover all the same material, but the organization and amount of time spent on different parts would vary between the groups. Obviously, this would be a serious undertaking.
It’s not exactly the same, but this reminds me of the situation with Scala where you have three very distinct camps trying to shape the language in their own directions. You have the hardcore FP crowd that really just wants to write what’s been termed “Haskell fanfic” on the JVM; you have the people who just want to write Java in a way that’s not unbearably tedious, then you have the Scala Faithful who follow TypeSafe closely and use Akka for everything.
In the case of Scala it’s led to some pretty massive cultural fragmentation (from what I’ve seen as an outsider to the community). I’m not sure if the same is true of Rust because it does seem to have a more coherent vision; maybe the differences fade away as the learning progresses.
Yeah, in my experience with Rust everyone does end up in roughly the same place. The groups still have their own favorite ideas for what to do next in the language, but I also think everyone is reasonable enough and respectful enough toward each other to recognize which of the many possible ideas for progress is most important (right now that’s MIR, which will enable a bunch of other changes that benefit everyone).
The more interesting question is to ask what causes that misunderstanding, but this is a starting point. Just yesterday I read a presentation from somebody who said “C is really hard because I don’t understand pointers, but rust was easy.” Now, I do understand pointers, so will I find rust easy?
Now, I do understand pointers, so will I find rust easy?
Personally, I found Rust a lot easier once I started thinking of it as a more modern C, instead of a more modern C++ (which, for whatever odd reason, is how Rust seems to get pitched). There’s a lot more you have to ‘unlearn’ coming from C++.
This is probably why for people like me who know C++ but not C, D feels much more natural than Rust.
Btw, what are Rust’s compile-time abilities like? I really like that D allows metaprogramming in the same language as the runtime language (i.e. D). It’s not quite lisp, but it feels close.
I am not a D expert, but my understanding is that Rust’s metaprogramming is by-design not as powerful as D’s.
Rust has two metaprogramming systems: macros (which pattern match on the syntactic forms of their parameters to generate new code, and are hygienic), and compiler plugins, which include “procedural macros” (macros that run arbitrary Rust code that operates on the program’s AST at compile time), and custom derive rules (for auto-deriving traits). Additionally, Cargo build scripts can be used to do certain code generation work before crate compilation begins. This is used, for example, by some parser generator libraries, which will use a build script to generate their parsers' Rust code so it can be compiled with the rest of the crate.