Jay Taylor's notes

back to listing index

A Gentle Introduction to Rust | Hacker News

[web search]
Original source (news.ycombinator.com)
Tags: rust news.ycombinator.com
Clipped on: 2018-05-05
Image (Asset 1/2) alt=
Image (Asset 2/2) alt=
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.

So the uses are pretty hardcore: operating systems, device drivers and embedded systems that might not even have an operating system

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.

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.

> No mention of how you would remember that `f64` is the default floating point type

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

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


At my university course, we did C in the first year for all programming courses. THen onto C++ in year 2 onwards, but all the fundamentals were in C.

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

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.

Rust could be really great first language. After learning Rust programmer will write much more safe code.

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

Parsing with `nom` seems like a pretty aggressive introduction to Rust :)

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

When you search in the API documentation, you will find 3 tabs at the top: "In Names", "In Parameters" and "In Return Types".

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

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

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

That would be what Hoogle is for Haskell: https://www.haskell.org/hoogle/

Could you start by grepping API docs?

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

4th post with this title from this author.

I would assume they really care about getting new Rust devs.

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.

Thanks Donovan

The tutorial is also avaliable at slash tutorial https://slashtutorial.com/rust/

Why does every single rust promoting article have to bash on c++?

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

> Why does every single rust promoting article have to bash on c++?

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

> They built a GC, good job.


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

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.

> That doesn't mean discussions including it have to bash C or C++.

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

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.

«The incremental benefit in certain areas is small, and it steps backwards in other areas.»

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

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.

So nothing about ADT, pattern matching, modules, better std, explicit unsafe and cargo?

I skipped over modules, because Visual C++ and clang already have them in some form, it is a matter of getting them standardized in C++20.

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


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.



Yes. C++ has all of this in a crippled form. But it doesn't mean that C++ in on par with Rust.

Not from technical perfection point of view, but it is much easier to improve existing codebases than just rewriting the world.

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.

I'm not saying that you should ditch an existing C++ project.

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

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.

You did not list any steps backwards just that the ecosystem is less mature

Sure I did, lack of SIMD and GPGPU support for example.

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.

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 does work on game consoles, embedded platforms, mobile, and more as well.

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

Yea I realize it compiles to LLVM and this can technically target anything. It's the toolchain, profiler, and debugger maturity that worries me.

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

Yeah, we’ll see. Chucklefish, as far as I know, has been happy. I did a presentation at an Activision studio yesterday. We’ll see!

Maybe I'm living in a special kind of bubble, but I have yet to meet a C++ programmer IRL who doesn't hate it.

There are dozens of us. Dozens! You need to search for programmers that have problems in the microsecond to millisecond scale.

Hello, now you know me. I leave that special spot for C.

Say what you want about C, but at least it doesn't require reading several LotR length books, to be up to date with all the stuff.

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

Actually it does, for anyone that cares about how to write portable and safe code in C.

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

C is a simple language. It has order of magnitude less concepts than C++. It's application is complex.

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

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.

Who built a GC?

Manishearth did, as an experiment. :)


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact