Log in

No account? Create an account
Previous Entry Share Next Entry
[For the programmers]

I just spent an hour doing a quick skim of the Rust programming language, which has hit its 1.0 release. I was pleasantly surprised.

I'd heard Rust billed as "a better version of C", and my reaction was basically ho-hum, I've heard *that* song and dance too many times before, and I haven't been especially impressed. But Rust is different: they're not trying to take C and make it a little bit better. Instead, they set out to create an entirely new language with the same *purpose* as C -- close to the metal, blazingly fast -- but with a vastly more sophisticated syntax and compiler, that automatically prevents most of the common pitfalls of C and C++.

The big deal here is the memory model, which is weird and fascinating. Instead of the usual approaches of garbage-collection (with its unpredictable pauses) or reference-counting (which is easy to screw up), Rust has a frighteningly simple concept that you can and must have exactly one "owning" pointer to any given memory item at any given time; when that owner goes out of scope, the item gets flushed. There are many idiosyncratic effects of this: the documentation goes into lots of detail about concepts like "borrowing" and "lifetimes", and it looks like it takes a while to get the hang of it. But if that saves you from the usual C/C++ headaches of memory-management, that's still likely a gigantic win.

That aside, it's a surprisingly modern language all around. While I'm not going to trade Scala in for Rust, it *does* manage to include both decent-looking OO tools (its "trait" model looks very much like it was adapted from Scala) and at least the crucial bits of functional-programming support (closures, higher-order functions). Heck, it even has hygienic macros. And while the language is strongly opinionated about good programming practices, it *does* provide you with the loopholes you need in order to do dangerous stuff when necessary.

Overall, it's clearly well-thought-out and seems intriguing. It looks like working in it probably wouldn't make me want to shoot myself in the head, which puts it ahead of most languages (including Java 6). It's pretty obviously a better choice than C, and likely is strictly superior to C++ in every respect. So if you're doing at-the-metal coding, where every cycle counts, I recommend giving it a read...

  • 1
I've been reading about it too, and one article pointed out that it also has what most other new languages don't; a big player backing it and likely to be implementing in a world class product. Mozilla has the pockets and name and open source community strength needed to make it a successful language.

Thanks for pointing out that it hit 1.0. I looked at it a few months ago and it looked very promising.

I'm glad you took a look at it. As (i think) I mentioned over the weekend, some people at my company are interested in it, but i haven't spent as much time evaluating languages to get a good idea of how worthwhile it is.

Yeah, thanks for mentioning it. Between that and the Ars Technica article saying that it had hit 1.0, I gave the manual a quick read. I'm genuinely surprised that it doesn't seem to be missing anything I consider crucial. (Heck, its "pub use" mechanism is one that we've argued about wanting in the Scala community for eons.)

The memory model sounds like a baked-in version of the "unique_ptr" type in C++. I gather Google developed something similar internally, and was encouraging its use, before unique_ptr was incorporated into the C++11 standard. Anyway, most pointers in new Google C++ code are unique_ptrs. (There's also something called "scoped_ptr", which drops the uniqueness restriction and is copyable, but we're not encouraged to use it unless absolutely necessary.)

Of course, due to compatibility, there are still old C-style pointers and a lot of library functions that require them; as one would expect, most of the memory-management bugs I run into arise from conversion between unique_ptr and pointer.

Ah -- unique_ptr is new to me, but I last did much in C++ around 2002, and have since been mainly working in the virtual-machine world; presumably best practices have evolved a ways since then...

I last did much in C++ around 2002
Me too. When I came to Google, I wasn't looking forward to working in it, but they made a lot of improvements while I wasn't looking. I'd still rather program in Racket or something like that (haven't really learned Scala or Clojure or Go yet), but it's almost tolerable.

One of the C++ gurus at Google (who I think is also a macher in the C++ standards world) explained that, about 10-15 years ago, there was a conceptual breakthrough in how to teach pointers and memory management: every block of memory has a unique owner, who is exclusively responsible for deallocating it eventually. Ownership may be transferred but not disclaimed (without deallocating) or duplicated. They then used standard C++ techniques (a lot of operator overloading) and RAII (or "How I Stopped Worrying and Learned to Love Destructors") to build classes that support this style of programming and enforce these restrictions.

Unique pointers (in any language) may never be quite as convenient as automatic garbage collection, but they provide (as you say) predictable, close-to-the-metal control without the safety problems of traditional pointers.

Edited at 2015-05-19 02:25 pm (UTC)

Yeah, seems like a reasonable compromise. Certainly, if the tooling support is good, it seems more reliable than the COM-style refcounting we did in all the C++ code I worked on at Looking Glass, Trenza and Buzzpad. (Which worked, but required a *ton* of macro support to use it without frequent errors.)

(And wow -- the Trenza website is still up, fifteen years after the company folded. Who says the Web is ephemeral?)

  • 1