Thoughts on Rust?

At the risk of repeating myself, Rust is interesting, but like many largely academic languages, far from ready for production use (in a few years? maybe).

On the plus side, they have demonstrated the balls to turn accepted software development on its head, say "to hell with this", and provide a model of unique reference ownership which is sure to make most programmers twitchy, but is the first good idea in a decade of discussions over the pros and cons of garbage collection. On the down side, they didn't leave garbage collection out entirely.

Most of the rest of it is a collection of the usual "meld the latest functional and parallel wotsits onto C" philosophy that C++, Go and Swift are all similarly chasing...

I plan to add more to the discussion when I have a bit of time, but I personally don't lump Rust into the "academic" language camp, like I would, say, Haskell. Aside from the memory safety aspects, its not really a big-agenda language, as most academic languages are. They have an opinion of what is useful and pure, but they seem to be moving along with an eye towards pragmatism. People are doing interesting things in Rust now, and Mozilla is committing to using it in production, client-side code in a more significant way than even Google is with Go. My own guess is that Rust will prove out to be a useful branch on the evolutionary tree of programming languages.

For games, I think the immediate question is whether the extra memory safety will be in the way of things we are all used to doing in C and C++ as game programmers, and whether and how long we will develop abstractions or learn ways of segmenting that code off in Rust's unsafe blocks, while still letting us do the bulk of our work under and within the bounds of its the greater memory safety. If the industry or early adopters were to show that it is possible, then the wins are very tangible.

On the down side, they didn't leave garbage collection out entirely.

But neither is it in the core language -- its a standard library module. Rust can run on bare-metal with no runtime, all it needs is a stack.

Frankly it doesn't sound much different then C++ making RTTI optional.

Rust is a classic example of what happens when you try to anticipate everything that could ever go wrong, and then build a language feature that tries to make that less dangerous.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." - CAR Hoare.

Frankly it doesn't sound much different then C++ making RTTI optional.

C++ needs its runtime for a lot more than RTTI. My understanding of C++ is that its so limited without its runtime as to be nearly useless. Rust seems to retain much of its character still, and certainly has enough expressivity to bootstrap its full self.

Rust is a classic example of what happens when you try to anticipate everything that could ever go wrong, and then build a language feature that tries to make that less dangerous."There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." - CAR Hoare.

How recently have you looked at it? I certainly respect your opinions on programming languages, but I'm curious as they've really cleaned up a lot of the cumbersome syntactic patters that had appeared. The language has become markedly clearer in the past 6 months or so.

On the down side, they didn't leave garbage collection out entirely.

There is no GC in Rust. Not even as a library.

They're removing the GC'd pointer type since its existence is a bald-faced lie (it's implemented via a reference counting implementing).

C++ needs its runtime for a lot more than RTTI. My understanding of C++ is that its so limited without its runtime as to be nearly useless. Rust seems to retain much of its character still, and certainly has enough expressivity to bootstrap its full self.

Depends on implementation. You need RTTI for typeid and dynamic_cast, you need a library of some kind for IOStreams and any other parts of the standard library that aren't purely in headers (today, that's likely to include std::thread and a few others), you need a stack unwinding library (same as Rust), etc.

You've been able to use C++ without more than libc (or even without that) on UNIX-like systems for many years. You just have to switch off various language features and avoid certain library calls that game developers tend to hate anyway (RTTI, exceptions, IOStreams, etc.).

Rust is a classic example of what happens when you try to anticipate everything that could ever go wrong, and then build a language feature that tries to make that less dangerous.

Not really. They're using a functional design pattern that many consider to be simpler, easier to reason about, and easier to teach. The only funky thing they've really added that is in any way new, complicated, or not (yet) fully understood is the explicit lifetime markup, which gets simpler as time goes on.

The standard library is different, but more fault tolerant. Its standard threading model is based on isolates, for example, though you're still able to use plain threads and hard-to-debug C-like synchronization primitives if you really want.


I think it's 5-10 years out before Rust has even a shot of becoming mainstream. A large part of this is inertia. In games, for instance, we need not only ports/wrappers of open source libraryes but also for things like Havok, Scaleform, Enlighten, Umbra, Morpheme, WWise, and dozens and dozens of other libraries. C++ libraries that cannot be easily imported with Rust's macro-unfriendly C-only FFI interfaces. This is the same problem faced by Go, D, and all the other C++ killers: C++ went unchallenged long enough that it's now almost at the same level as C in terms of being a core glue language, yet it's so complex and so much is dependent on parsing its full headers (seeing vtable layouts, for instance) that supporting it in your FFI system is damn hard.

My background: for the little I delved in game programming with C++, I was absolutely scared of the language. Previously, I was programming in C#/Java, and C++ with its manual memory management was so scary I switched completely to "modern" C++11 and used shared_ptr absolutely everywhere. Then my enthusiasm got drowned by "serious" work in PHP "language". And Javascript. I am a huge fan of finding problems on developer machine, and not runtime. And scripting languages are in absolutely the farthest distance from that ideal.

Year and a half later, I found Rust. It is like a breath of fresh air. It has the right idea. It is not that it is "killer" of some particular language. It simply stands out because it leaves less problems for runtime than any language I used before.

I am not saying that "Rust" is special. No, the idea of "ownership" and "borrowing" is special. Even if by some unfortunate event Rust dies, other languages are going to pick up this idea.

How else to explain it? Well, you know, how we find elements in map quickly? We keep it sorted. How do we quickly calculate statistics for the large amount of data? Well, we aggregate it as the data comes in. How do we avoid collecting garbage in language to ensure memory safety? Well, we define strict rules so we can know when all data is deleted at compile time. duh.

Yeah, I know, it sounds like Rust turned me into a fan

No, the idea of "ownership" and "borrowing" is special. Even if by some unfortunate event Rust dies, other languages are going to pick up this idea.

They aren't new ideas. Rust's ownership rules implement (some subset of) a linear type system, which have been around since at least Linear LISP in the early 90's.

Of course, classical linearly typed languages are mostly very hard to program or reason in, while Rust offers a fairly novel method of integrating a linear type system into a C-like language - I think that is likely to be one of its more lasting contributions.

I think it's 5-10 years out before Rust has even a shot of becoming mainstream. A large part of this is inertia. In games, for instance, we need not only ports/wrappers of open source libraryes but also for things like... . This is the same problem faced by Go, D, and all the other C++ killers...

For mainstream games use, we also need compilers to exist for esoteric CPU's under closed platforms, where only other game-devs are allowed to tread - locking out typical open source contributors and requiring a decent amount of demand to exist if a commercial provider is to step in. Chicken and egg ensues, where we can't use it because there's no compiler, and there's no compiler because no one is using it.
You need a PC devs to invest heavily and then transition to mainstream games, forcing them to develop/port the compilers themselves ;D