Speaking as someone who's poked around at the edges of Rust and always come away frustrated, the Rust world does need a "gentle introduction". But while this document seems to understand that need, it gets messy pretty fast.
First of all, the introduction is all over the place, and poorly structured. There first section asks "Why Learn a new Programming Language?" but never answers that question (beyond "it's good mental exercise"), and follows it up with a section labelled "Where Rust Shines" that instead vaguely compares its memory management approach to C, calls C a "cowboy language", lists some of Rust's design components (not really even principles, just aspects of the language), and then starts giving advice for how to learn a programming language in general? What?
Next is Hello World, and immediately "Rust is a curly-braces language with semicolons, C++-style comments and a main function - so far, so familiar." Well, to C++/Java/Javascript programmers, maybe it is familiar. That may well be a huge part of your intended audience, but this gloss of the basics is a big red flag about what assumptions might be made further on.
"The exclamation mark indicates that this is a macro call. For C++ programmers, this can be a turn-off, since they are used to seriously stupid C macros"
Whoa, there, cowboy! This is Hello World! Mentioning macros at all should probably be reserved for a little later, much less vaguely referencing the C preprocessor's bad repuation. Then the tangent about "OMG, you mean I have to type an exclamation point!?" is telling, though. At this point in a gentle introduction, you probably shouldn't be already alluding to the trash talking about the language.
We aren't even past the first example. Further down the page, there's some big talk about how Rust favors explicitness, immediately followed by a discussion of how all the types are implicit and how confusing that can be. No mention of how you would remember that `f64` is the default floating point type...
This is a worthy attempt and probably a good first draft. It's definitely a document that needs to exist, but in its current state, it's an gentle intro that only a disaffected C++ programmer could love. But please keep working on it--I need something like this.
"Disaffected C++ programmer" is altogether too accurate characterization of the author :). I've been removing references to other languages because (a) it's confusing (b) can be dismissive ("trash talking") - a language should stand on its own merits. So yes, a first draft.
I try to express the paradox - that although Rust is about explicitness, type inference hides the actual concrete types chosen - `f64` and `i32` are examples. This needs to be made .. explicit.
Personally I don't think it's possible for people with no prior exposure to programming to learn Rust effectively - unless they are exceptional (in the sense of being 'unusual'). This is because of certain hard constraints when learning a systems language that can't simplify computational models with a garbage collector. So, everyone comes from somewhere - but very different places. That's a challenge I haven't handled well enough (yet).
Being gentle is hard. We have to identify the cliffs, and find alternative routes to the top. I really appreciate this criticism, by the way, since most of the feedback has been technical/typos up to now.
I'm a big fan of ripgrep, and there's been a minor revival of command-line tools exploiting the speed + higher-level + reusable-crates that Rust provides. So 'hardcore' is not correct. I've personally found it very effective at writing such tools - I struggle a little more, but debug less.
Let's not forget server-side: I'm still recovering from the trauma of mysterious segfaults when doing C++ on the server, which can easily happen with multithreading and are an absolute bastard to diagnose and fix.
I think you are a little unfair, expecting the guide to be towards complete beginners who would get confused by the language having curly braces or not...
Rust is not a first language, it's a systems programming language. For previous programmers, the guide looks pretty good to me.
> Rust is not a first language, it's a systems programming language.
Since when are sys prog langs not introductory languages anymore? I understand that using an dyn typed, interpreted, GCed lang is easier to get started with; but a whole (2) generation(s) of programmers has started with systems programming as their first experience, and I must say they seem well equipped for they jobs (maybe better so than those only exposed to Python/JS/Java/C# that leave higher educations nowadays).
I see it as two different educational strategies: easy first vs hard first. And even when easy first was not an option back in the days, it does not mean that hard first is a bad option nowadays.
A ref to this letter by Dijkstra may be on point (where he "discusses" the move from Scheme/Haskell to Python/Java in a university curriculum).
I also thing that a systems programming language should be a must on for any CS degree. Just so you know how the software is written that underpins/compiles/provides-the-runtime-for what you are creating in a higher level language. It's the link between the software and the hardware that becomes truly evident in these languages.
Arguably, school curricula are driven by the industry's needs. People keep asking for Java and Javascript developers, so that's what they have students learn.
I guess my response to that would be, if you just go straight into Java then OK, you've made some Java developers... I think they will be poor developers who happen to know Java.
But if you teach them fundamentals of structuring software, compiler theory, how it all works at a lower level etc. Then teach them Java, you will have good developers, who also happen to know Java.
Thanks, that's a great letter which should get more exposure. The issue is ultimately vocational vs. professional. If someone wants to do data science then Python is appropriate, but someone who is going on to do CS is going to need something more rigorous. Traditionally there are two kinds of rigour (a) systems language with explicit memory management (learning the machine model) (b) functional language like Haskell or Scheme that forces a reboot of "what does programming mean?" and makes mathematical reasoning possible. With the right curriculum and supporting materials, Rust is nicely positioned to accommodate both kinds of rigour.
I'm not saying any way is better than the other. I see advantages/disadvantages either way. I do thing we should have a broad view, especially in higher education (not simply teach the specific trick that the industry needs, but teach generic skills that work no matter what field they are applied to).
While I was on the advisory board of an institution of higher education I tried to show them that "going with JS in the first year" because it is such a lingua franca is IMHO not the best choice. They did it anyway. They want the students to make flashy apps asap. I was proposing to use the SICP for the first years, mainly for two reasons:
* create a leveled playing field, as some students already know JS before starting the course
* learn concepts, not how-to-make-an-app (for which you have to know many techs that simply clutter the minds, like HTML and CSS)
> With the right curriculum and supporting materials, Rust is nicely positioned to accommodate both kinds of rigour.
Disagree. I think it does the (a) thing well, but only little of the (b) thing.
Personally I really dislike documentation with this tone, written as if speaking to a minor, even when I was 11 yrs old and getting to know what programming is like.
Really enjoyed the section on error handling. I had read similar sections in the rust book, but something about this explanation really made things click for me! As much as I love Rust, I personally found it a little difficult to get used to the error handling coming from an language like JS which cares little about appropriate handling
I got carried away with a personal enthusiasm. It happens :) `nom` is marvelous, but the hard bit with combinatorial parsers is getting them to spew out good error messages. By default they are like Prolog - the answer is 'no'.
What makes Rust still rather inaccessible for me is the difficulty in finding «functions I can apply to an argument of type X» and «functions that return a value of type Y» other than, “read every last bit of API doc about everything and memorize it”.
The official docs have limited support for it, if you search for i32[0] the default facet is "in names" but you can use the "in parameters" and "in return types" tabs for these. I don't know how well these handle abstract types and it's nowhere near hoogle convenience, but there you are (there were efforts to port/replicate hoogle a few years back but the few I remember seem to have been abandoned, specifying a search syntax is probably non-trivial as well given Rust's signatures are not as convenient as Haskell's there)/
As a Go dev that learned programming via Zed Shaw's learn python the hard way, I have to say this tutorial made me want to learn rust.
I've bookmarked for later, once I'm done learning dart/flutter.
That doesn't mean discussions including it have to bash C or C++. In fact, there is supposedly a very high standard in the official Rust community against bashing other languages.
Plenty of languages have completely replaced or circumvented C and C++ (i.e., out-competed them) in their respective niches without it being a heated two-minutes hate every time discussions come up.
I approve whole-heartedly of the "no zealotry" rule. (I seriously doubt that the Jehovah's Witnesses have achieved conversion rates commensurate with the effort expended.) That being said, C has problems, particularly the assumption of the "sufficiently smart programmer". Because I'm not smart enough, I appreciate the nagging of the Rust borrow checker, although to be honest it is a complete pain at first.
To me, it feels like Rust really only has value to people who aren't already using C++14/17. The incremental benefit in certain areas is small, and it steps backwards in other areas.
Rust is better in that it enforces at language level best practices regarding memory use and thread safety, that are only possible in C++ via conventions or external tools like sanitizers.
C++ still wins down on available compilers, supported hardware and OSes, IDEs, debuggers, libraries, GUI tooling, SIMD, GPGPU, industry certifications for critical systems, ...
For example AUTOSAR just recently moved away from C to C++14 as suggested language for car computer systems, imagine how long it will take for them to suggest other language.
A programming language is not just a grammar and semantics.
The whole eco-system and community around a language is what defines it.
To give a more explicit example, until it reaches parity with C++ on .NET/UWP tooling, it just means less productivity in spite of being a technically better and safer language.
Assuming nothing catastrophic happens in the next five days, https://github.com/rust-lang/rust/pull/49664 can be merged, by the way. So that'll be one thing off your list as of 1.27.
I write multithreaded code all the time. I simply do not encounter the amount of "pain" that is touted as the reason things like the borrow checker need to exist. Generally, you write abstractions around synchronization and asynchronous dispatch and then just use them. C++ works on platforms like PS4, mobile devices, embedded, and more already with good support from vendor toolchains. If I use Rust, I have to use all these wrapping libraries or write my own. Yea the syntax can be pretty in some ways, but I already have structured bindings in C++17 and a whole bunch of other things I can do.
Rust finally provides an alternative to C++ in one of the few niches that still mandated C/C++, and now that there is an alternative, it's easy for people to get carried away with evangelism.
I'm obviously a fan, but evangelism does not sit easily with engineering. Can alienate outsiders, and pump up a positive bubble in which sound criticism might be neglected. (In fact, /r/rust has a 'no zealotry' rule.) This submission was not my idea, even though I'm not _too_ embarrassed.
First of all, the introduction is all over the place, and poorly structured. There first section asks "Why Learn a new Programming Language?" but never answers that question (beyond "it's good mental exercise"), and follows it up with a section labelled "Where Rust Shines" that instead vaguely compares its memory management approach to C, calls C a "cowboy language", lists some of Rust's design components (not really even principles, just aspects of the language), and then starts giving advice for how to learn a programming language in general? What?
Next is Hello World, and immediately "Rust is a curly-braces language with semicolons, C++-style comments and a main function - so far, so familiar." Well, to C++/Java/Javascript programmers, maybe it is familiar. That may well be a huge part of your intended audience, but this gloss of the basics is a big red flag about what assumptions might be made further on.
"The exclamation mark indicates that this is a macro call. For C++ programmers, this can be a turn-off, since they are used to seriously stupid C macros"
Whoa, there, cowboy! This is Hello World! Mentioning macros at all should probably be reserved for a little later, much less vaguely referencing the C preprocessor's bad repuation. Then the tangent about "OMG, you mean I have to type an exclamation point!?" is telling, though. At this point in a gentle introduction, you probably shouldn't be already alluding to the trash talking about the language.
We aren't even past the first example. Further down the page, there's some big talk about how Rust favors explicitness, immediately followed by a discussion of how all the types are implicit and how confusing that can be. No mention of how you would remember that `f64` is the default floating point type...
This is a worthy attempt and probably a good first draft. It's definitely a document that needs to exist, but in its current state, it's an gentle intro that only a disaffected C++ programmer could love. But please keep working on it--I need something like this.