From Rust To Dust
One evening a programmer was strolling along the beach, barefoot. It was an oddly warm day in the indian summer. The sky lit up in red as the sun started to set. Yikes!! A sharp sting flashed through his big toe. Instinctively, he pulled his leg up. A small red crab snapped its pinchers, and quickly crawled its way sideways.
I figured out why the Rust mascot is a crab. Not because it’s a crabby compiler, and not because it’s hard on the outside, soft on the inside. No sir, it’s because it crawls … at a slow pace … sideways. Productivity in Rust is low. After two years of coding in Rust I can confidently say I have firm grasp of the most important aspects of Rust, and still it is a struggle, every time, to get anything substantial done in this language. Rust is a great language with amazing features, yet it is being impossible.
Rust is great when it works, but often it’s not working in your favor, and then you have to solve a puzzle of how to make it work. It’s mindboggling and energy draining.
Rust works well for problems that can be written down in a purely functional
style; A transforms into B. Foreach X apply function Y.
While it seems logical that all software should work this way, I keep
running into situations where Rust is not cooperative. A simple thing like
iterating over a mutable vector in a struct suddenly turns ugly when
you need to update a flag elsewhere in there, while the memory already was
mutably borrowed … you can’t do that.
And so you have to resort to weird refactoring, or entirely disassembling
this structure and dividing up the memory in an other way.
How to solve it this time? Keeping a grocery list of updates to perform, rather than just coding the updates as-is? I can keep solving puzzles, but I just don’t have the grit anymore. Rust is being pedantically overprotective.
Skill issue? The weird thing is, you think you get better at it, keeping you endlessly invested in taking it one step further. If you consider that time is money, then Rust is exponentially expensive.
Rust is a cult, and you’ll never know how free you are until you get out.
The next day our programmer went pawing through the water. The sea was cold, but refreshing. There was a slight breeze, and he took in the smell of salt in the air. He stroked his beard in deep thought, and enjoyed the warmth of the sun on his skin.
I picked up Odin and recreated my Rusty game project (that I spent six weekends sweating over) in a single day. I feel clumsy when googling “Odin” because too many projects bear the same name—of course, I’m talking about the game development language.
Odin is an awesome language that makes you fly in code. I want to call Odin
‘a better C’, but it’s actually closer to Pascal with curly braces.
Its novel declaration syntax with double colons (borrowed from Jai) feels
remarkably consistent and smooth. A more conventional choice of keyword-first
however would have been better language design in the long run.
I genuinely miss the const
keyword for declaring constants.
I like the strict typing (no implicit integer conversions), and the enums work exactly the way I want them: symbolic constants, but they are flexible enough to double as bit flags stored in an integer of a specific size.
For safety Odin performs bounds checking on arrays, and there is no pointer arithmetic. Other than that, Odin is pretty unsafe. It requires you to do manual memory management, and I did create a memory leak at first, hoozay!
Odin has a number of advanced features not found in many languages, such as
SIMD support, structure of arrays data layout, a built-in matrix
type,
the ability to change the default memory allocator. There is no OOP and
there are no struct methods in Odin.
Overall, I really enjoyed coding in Odin—it has great flow; it is such a breeze. Odin is fun to use.
The day after, our programmer collected some stranded wood and rope. He was on a mission, and started building a raft from the materials. He worked throughout the entire day, tying it all together. He added some bamboo, and finally a plastic barrel that he found. The raft wasn’t built like an oil tanker, but it was definitely strong enough to carry him to the next island.
I picked up Go and recoded the very same project the next day.
I dislike the CamelCasing, and I dislike what go fmt
does to whitespacing
around operators (it likes removing whitespace altogether on occasion).
Get over it, and Go is awesome.
Golang is mostly successful in the world of web backend development. It is kind of a shame really, because Go is a general purpose language, that is capable of so much more. People seem to associate it with a scripting language, I can’t recount the times having to tell that Go compiles to binary, delivering good, highly performant code.
It features a “stop the world” garbage collector, which is an under the hood system, outside the control of the programmer. This turns off many a coder. In practice I’ve had zero problems with it whatsoever. A tight game loop shouldn’t do many dynamic memory allocations anyway (use an entity pool instead). The nice thing about having a garbage collector is that memory management no longer is any issue; you simply don’t have to think about it. This frees up a lot of headspace, making life easier.
Coming from C, it’s both weird and amazing that in Go you can declare a local struct variable and return its address … the compiler will heap-allocate it for you, so no harm done. You don’t have to worry about freeing that pointer, because again, garbage collector. No worries about double frees, either.
For extra safety, Go arrays are bounds checked, and there is no pointer arithmetic. Go’s most impressive features are duck typing and its unsurpassed multithreading support: goroutines that communicate via channels.
Slightly confusing: should I write struct methods or simply use functions that take a pointer? The takeaway is to do what feels best, what creates the nicest API for this particular data structure. Go acknowledges that data is just data, but sometimes it is nice to have the syntactic sugar of being able to write things in a classy style.
Go has a reputation of being boring, and I agree it tastes kind of dry. But this language simply gets work done.
Our programmer paddled his way to the next island. He set foot on new shores. He looked around and stroked his beard. At first glance, the place looked deserted. He spotted some cottages beyond the treeline. This was going to be alright.