This is one of the coolest things to have in the standard documentation, IMO. Rust claims to be good for replacing C/C++ where other languages can’t and shows you in detail how it could be done in a semi-realistic example.

it’s a systems language that doesn’t feel like a systems language

This is how I feel about it, too. Once you understand ownership and borrowing well enough, it doesn’t make you jump through hoops to do things the way you’d do them in higher-level languages.

This is how I feel about it, too. Once you understand ownership and borrowing well enough, it doesn’t make you jump through hoops to do things the way you’d do them in higher-level languages.

Hm, I’m not sure - for me, it feels very much like one. What I love about Rust though is that it doesn’t take the route of “You have to know all these things and things break if you don’t!”, but encodes many of them.

For example, many things are possible when you know the size of the type at hand and some are not if you don’t. Rust makes that very explicit: using the Sized trait. Coming (back[1]) from dynamic languages, that helped me a lot. It gave me enough info to start thinking about this issue and helped me form my mental model again.

As a haskeller (and ocasional ocamler), rust is very interesting (and a while back I contributed a little bit), but unless you need manual memory management (which most of my work doesn’t), it’s a pretty hard sell over haskell (and I don’t say that disparagingly - safe manual memory management is really hard! And rust does it well, but manual is manual!)

What I mean by ‘manual memory management’ is needing to understand when memory is allocated, when it is copied, and when it is freed. The way Rust does it is definitely better than malloc and free, but you still have to think about lifetimes, borrowing, etc. The compiler can statically rule out all of the unsafe uses (and some of the safe ones), but it still, at least to me, feels manual. Or at least it definitely did when I was last using it (granted, a couple years ago, but my impression has been that that part of the language has actually been relatively stable).

If you are working on that level, you also have to know that in a GCed language. It is not unusual for collections in those languages to differ in their allocation strategies for example (compare the huge amount of collections in Java that differ in allocation semantics).

Rust currently has rather simple allocation/deallocation rules that more compare to refcounted languages and is completely hidden from you. It is unusual to work with them, but I don’t see anything manual about them. Maybe the term just doesn’t cut it anymore.

(Actually, as a side note - in simple terms, Rusts model is counting owners where only one owner is allowed)

I’m pretty sure rust gives me most of what I want out of a type system, but also the complexity of not being GCed. I think a GCed Rust might look pretty ideal to me, i’m starting to play with it now as I’m hopeful that the type system makes the lack of GC easy enough to swallow.

Rust used to have a GC and it was thrown out after the decision to go for a runtimeless language. Be aware that Rust operates at a space where you often implement parts of a larger program - embedding a library with a GC runtime into a language with another GC runtime makes reasoning about the memory space of the program really hard.

Also, please be aware that there is a huge project written in Rust during the whole development phase: Servo. If they can switch away from GC, so can you.