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.

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 think this falls a little short. Think of tools like ripgrep which make use of C/C++-class speed with higher level language features.

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.

While the default is `f64`, it's only used if the type can't be inferred otherwise.

If the author had changed the `f64` in the code sample to `f32`, type inference would have made the float literal to be an `f32` to match.

That is a little complicated to explain, but the UX is such that literals generally "just work".

Rust is not a first language, it's a systems programming language. For previous programmers, the guide looks pretty good to me.

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).

https://chrisdone.com/posts/dijkstra-haskell-java

Now that same course goes straight to Java as the introductory language, alongside html / css and javascript.

Now any sort of low(er) level language is avoid until year 2 when they do a course on C / C++

Which seems ass backwards to me.

I also see some developers come into the industry now who have never done anything lower level than Java or javascript at all

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.

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.

Example: https://doc.rust-lang.org/std/?search=option

[0] https://doc.rust-lang.org/std/?search=i32

Could you start by grepping API docs?

Of course, but that's still painfully slow and awkward. It's exactly the kind of repetitive crap we programmers are born to automate.

Thanks Donovan

They built a GC, good job. But, surely there is something else more worthy of typing about when hyping the language?

Because it was built to be a C/C++ replacement.

> They built a GC, good job.

?

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.

One mans critique is another mans bashing. Though admittedly I did not really read the article.

As someone who doesn't know about C++ and Rust, can you elaborate on that?

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.

Cargo is great, but C++ also has conan and vcpkg, eventually a standard one will emerge.

http://www.klabbers.nl/c/dependency-management-for-c/

Also I do have an issue with Cargo's lack of support for binary libraries.

ADTs, while not as good as in ML languages, at least there is std::variant.

I kind of mentioned explicit unsafe when I refereed to the safety enforced at language level instead of conventions and sanitizers.

Pattern matching is a great feature across all ML based languages, there were already some attempts to add it to the C++ as well.

http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0095r1....

https://www.youtube.com/watch?v=HaZ1UQXnuC8

One of the things Rust should focus on as productivity improvement is making that migration as easy as possible.

Right now I cannot justify from business perspective replacing C++ with Rust on the workflows we still use C++ for.

But it doesn't mean that C++ as good as Rust. It's just wrong.

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.

If you prefer to be more specific, generics in Rust are still not as powerful as in C++, lacking const parameters and HKT, although they are coming.

Also compile time code execution is not yet supported, although quite a bit can be achieved with macros.

That said, you should use tech that you’re happy with.

> That said, you should use tech that you're happy with

Yea this summarizes what I was going for originally. Newcomers may benefit more learning Rust (I don't actually know this for sure).

Sadly, Rust, seems to be getting a few tomes of its own as well :P

There is this myth that C is a simple language, when devs stick to a single OS/compiler combo.

In same way Lisp is a simple language, but its application can be just as complex.

https://github.com/Manishearth/rust-gc