Although I haven’t written much on it, I have been a long-time critic of the Rust programming language, for various reasons. Today I will write on several issues I have identified with the language, from several angles. These include:
The first issue is pretty simple, and we see much the same going on with JavaScript and Go. Install a package, and there’s a 90% chance in a year’s time it’s broken beyond trivial repair. Unfortunately for Rust, it doesn’t have the approachability that Go and JavaScript have, so rolling your own stuff on an as-needed basis is too tall an order for most. So far, there’s no solution for this in sight.
The remainder of the issues comprise the bulk of what I want to talk about. As a results-oriented person, I think of Rust like this: it’s a case study in the close relationship safe (“automatic”) memory management has with performance. At the outset, developers said, “We want memory safety becuase [billion-dollar mistake], but garbage collection runs like molasses! Hey, can’t we just make a memory-safe language without a GC, so it’ll be fast?” And that’s what they did. Never again were the assumptions about the GC or its performance critically examined to any effect. For years it’s been echoed “GC bad” like a terrible meme, nevermind how many times people have written things in Rust only to find it not performing that well.
Wouldn’t it be great to have a language with all of the safety and performance penalties of garbage collection, with none of the convenience of a garbage collector? This is Rust in a nutshell. The retort is always the same: “We’ve been working on it, it’s so much better than it was X years ago!” Never substantiated beyond the benchmark, the little toy applications the aficionados made to prove to themselves it’s sufficient. The recourse is always the same, too: “Just write the code you need to in unsafe blocks.” Isn’t that funny? Why don’t I just write C code when needed and bind it to Node? Don’t tell me it’s convenient because it’s the same language. If you look at C++ you’ll see at least 4 languages packed inside that. Last thing anyone needs is a trenchcoat-wearing trainwreck masquerading as one big guy.
Maybe they’re just optimistic. In their bones they believe, with enough care and effort that damn-near-nobody seems willing to expend, Rust could be the language its really meant to be. There’s just one problem: it’s been years it has had to prove its theorem. But much like Godot, we’ll be forever stuck in limbo waiting for it to come ‘round. It’s not here, and while I don’t know about you, I’m not holding my breath.
This sort of thinking is patently unscientific. If we are to continue with such a faithful approach to our work, we will soon become quacks, whether anybody notices or not. This is especially grave if the trend of commoditisation and commercialisation of programming languages continues, for reasons I hope are obvious. Nobody needs a manifesto in their programming; they need a tool to get their job done, whatever that may be. It’s not the designer’s place to tell users what for, or why, nor is it acceptable for them to give false hope about their solution for personal gain. If someone is telling you Rust is simultaneously safe and performant, they’re either ignorant or are lying to you. As a matter of fact, it isn’t.
A lot of times I hear aficionados of newfangled languages like Rust bemoaning the legacy of C. In the classic fashion of somebody who has never used C with any goal at hand, they talk a lot about how terrible NULL is, or if they’re half-clever they’ll talk about imaginary constructs of ‘safety’ like someone who just heard about OOP and how intuitive it is. But hey, did you know you can have all of the things you need in C, too? Just think of it like checking for nil in Go if you really have to. Did you know you can make constructs that avoid the possibility of NULL altogether? It’s called Data Oriented Design, and it’s totally doable in C. You’d be surprised how many obstacles lie not in the language, but in your own approach to problem solving. Or if you already knew there was no other way, that buying your way out of the chores of NULL-checking or divesting it into libraries were futile, perhaps you were well aware? In that case you’re well ahead of the rest.
Until next time,
Άλέξανδερ Νιχολί