Empowerment

This is my first blog post! Since quarantine started, I’ve been working on a new video game. In some other post, I’ll put more details about the game, its implementation, and some cool shit I learned along the way, but today I’m going to talk about Rust. The game engine I’ve been using has Rust bindings, so I’ve taken the opportunity to learn that.

I’ve been working in Rust for about a quarantine now. I’m going to compare it to Scala and Go because Rust has a lot of similar language features with Scala, but gets compared to Go because they have a similar runtime environment. After those comparison, I wanna spend some time talking about “empowerment” in programming languages and why I hesitate to use this power.

Scala

One time, I was on a 1:1 with my mentor at work. He was telling me about Options in Scala. “The function returns something or nothing.” I was like, “Wait, doesn’t that cover everything? How could a thing be something other than something or nothing. That’s not a revolutionary idea!?” “Exactly.”

Rust also has Options and now that I know about these features, I dislike coding without them. Having these explicit types catches SO many errors at compile time. It forces me to think about the all possible outcomes. If I have a data structure for a person, they may or may not have an email address. In other languages, you might set "" and let that semantically mean that a person doesn’t have an email address. In Rust (and with Options in general), you have something much more expressive and strict:

struct Person {
    email: Option<String>,
}

Pattern matching on these cases in Rust FORCES you to write code to handle the case when you have Some(value) and None. The compiler will throw a “yo, this match isn’t exhaustive” and catch all kinds of goodies for you.

I could go on about more features that exist in both languages, but this is my first blog post so I don’t wanna write that much.

Go

I honestly think that the only reason these two languages get compared so often is because you can compile statically linked, self-contained binaries with both of them. If you’re from Java world, this is like a fat-jar, but imagine not needing the jvm :gasp:. The two often get compared by their runtime overhead. I guess they’re similar, but I think it’s more important to compare the code writing experience, than to compare the resulting binaries.

If you were to start a new project and needed to decide on a programming language, you’d probably look at features of the language, look at how well the libraries in that language support the goal of the project. You’d probably look at how much this language is used at your company and try to align on tools etc etc. In general, you look at the technical pros and cons of the language.

If I were starting a new project and needed to choose between Go and Rust, the technical details would fall to the wayside. I think it’s much more important to look at the team writing the code.

In the last few months that I’ve spent writing Rust, I’ve smacked my face into my keyboard 42069 times. The learning curve is steep. Because of this, I would only choose to use Rust if I knew the team had as much patience as I do. I feel like every time the compiler throws me a red line, I’m learning. It’s really frustrating at times and I often feel like I’m not productive (which is a core feature of Go). I bet if I had a ratio of how many successful compiles I have to non-successful compiles, it’d be like 4% success rate. The compiler calls me stupid all the time.

That being said, tools are the kitties titties in Rust. Most errors in rust will yield a link to the error index page. There, you’ll find helpful examples of why your code is bad and how to fix it. The compiler even puts easy fixes in the error messages if it’s simple enough.

fn main() {
    let x = 5;
    x = 3;
}

will throw the WONDERFUL error…

error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:4:5
  |
3 |     let x = 5;
  |         -
  |         |
  |         first assignment to `x`
  |         help: make this binding mutable: `mut x`
4 |     x = 3;
  |     ^^^^^ cannot assign twice to immutable variable

error: aborting due to previous error

For more information about this error, try `rustc --explain E0384`.

help: make this binding mutable: 'mut x' is such a descriptive explanation and clearly tells you what the fix is, just in case you don’t care.

Unlimited Power

“Rust: A language empowering everyone to build reliable and efficient software.” Empowering is the keyword here. The language is extensible. You can write these things called macros that extend the language. I even found this quick one that implements Scala-like for comprehensions. Now, on the face of it, this sounds super dope. I warn against using it though. I generally stay away from extending the language because it makes your codebase esoteric. Even if brogrammer A knows Rust, if brogrammer B puts a bunch of weird macros in the code base, brogrammer A has that much more to learn before they can be a meaningful contributor. Scala also does this, but calls it something sexier: syntactic sugar.

I dislike when there are two ways to do the same thing. You get into these holy wars about how to write code when it doesn’t matter. If you just write a tool that has fewer ways to use it, you get less opinions and less arguments between engineers. The compiler has the final say about how to write code.

Go implements this pretty well. There are very few keywords in Go. Public functions start with a capital letter. Inheritance and generics got tossed. The language itself is pretty elegant in this way.

This is the other reason I would choose Go in a battle between Go and Rust for projects. It’s so much easier to write Go. If I’m starting a company in SF that streams Yoga lessons with goats, I’m gonna use Go. Any Kevin Chen, Nikhil, and brogrammer Chad could spin up a server pretty quickly with Go and it reads pretty easily compared to

esoteric_macro!();
let x = data.get_person()?;