The Advanced Rust Programming Language Book Draft

(How many times I've put a colon at the end of a Lua function line...)

I think that there's a place for both of these styles in the world. And perhaps this style can appeal to a person who struggles with the stereotype of computer programming as a serious, dry affair, bereft of human expression, the job of coder cogs in programming factories. Perhaps you could say that the serious style appeals to more people, but maybe that is actually a criticism of the population of programmers, and not of the work?

In regards to sounding childish, I find that in general to be an unusual criticism. Perhaps there are people who speak this way as adults simply because that is who they are? I guess C.S. Lewis sums up my feelings about "being childish":

Critics who treat 'adult' as a term of approval, instead of as a merely descriptive term, cannot be adult themselves. To be concerned about being grown up, to admire the grown up because it is grown up, to blush at the suspicion of being childish; these things are the marks of childhood and adolescence. And in childhood and adolescence they are, in moderation, healthy symptoms. Young things ought to want to grow. But to carry on into middle life or even into early manhood this concern about being adult is a mark of really arrested development. When I was ten, I read fairy tales in secret and would have been ashamed if I had been found doing so. Now that I am fifty I read them openly. When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up.

Looking at that Julia example, I find that far too dry and academic. (The presentation is great though, better design.) For a scientific computing audience it's probably ideal, but that isn't for me.

That said though, I don't see why an informal tone should preclude getting the information across and sprinkling in some humor -- all without sacrificing precision. Something like Bjarne Stroustrup's C++ book is a good example of how to retain both humor and a thorough treatment of the subject.

However I will say that Rust makes it a lot harder to accidentally leak resources (it's trivial adversarially -- but I don't consider that an interesting programming environment YMMV).

In e.g. Java you need to remember to `close` a File -- in Rust it will close itself as soon as you stop using it unless you do some wild things. We can't formally guarantee anything better than the Java scenario; it's equivalent to whoever you pass a file to having to call `close` on it.

However the defaults are reversed: In Java you don't close a File by default, and have to explicitly do something to close it. In Rust you close a File by default, and have to explicitly do something to not close it (mem::forget or Rc cycle).

This is a pretty general theme for the wins Rust provides: it picks the best default so simple things are simple, but gives you all the tools to bypass that default. By default you want to close files. By default you want to free memory. However you can leak these resources when it makes sense.

The most interesting case for me is our HashMap: we default to SipHash seeded with some OS entropy to prevent algorithmic complexity attacks. This is an explicit choice to protect our users against a relatively obscure problem. Honestly, it's probably not what most users of HashMap need. Determinism and speed is probably nicer. And yet the cost of not having that safety guard when you need it is pretty extreme.

However if you know what you're doing you can just grab a community crate with a different hasher and plug it into our HashMap. Easy as a single type annotation: https://github.com/shepmaster/twox-hash/blob/master/README.m...

Rust doesn't break RAII in the usual sense. The leak issue in Rust is not something that can be cleanly talked of in the context of other languages.

In all languages with RAII till now, it's possible to "leak" memory by sending things to a permablocked thread, or stuffing them in a global hashmap, or whatever. This is something that no compiler can prevent, and it may even be desired at times.

Rust has always allowed this sort of "leaking". So have all the other languages out there.

However, Rust has the concept of scoped/borrowed data -- data with a lifetime which cannot escape that scope. Stuff that isn't scoped is said to be `'static`, i.e. it's lifetime can be the lifetime of the whole program (we can keep moving it out of functions and throwing it between threads). Scoped data can't be shoved into a global hashmap or sent to a random blocked thread, because it's not allowed to escape its scope.

Except, it turns out that using stuff like Rc cycles, it's possible to leak such data too. This affects RAII guards which use lifetimes to bind themselves to a scope to say "run destructors when this particular scope ends" (this is different from "run destructors when this object is no longer accessible", because with regular objects they can be hoisted into a larger scope by moving).

Note that the entire issue is about _scoped_ data (data with a lifetime, containing borrowed references), which is not a concept that exists in other languages.

So Rust still provides de-facto leak safety via RAII, it's just that it is possible in safe Rust to leak stuff, but you have to be explicit about it (global hashmap, mem::forget, etc). This is unlike languages where you must `delete` the object explicitly to avoid leaks.