Carbon Zig Odin Nim
A gloomy night in a dark dungeon. A dark wizard sits by the fireplace. He casts some powder into the fire, while mumbling the words “carbon zig odin nim”. And with a puff of smoke, new programming languages were unleashed onto the internets, capturing the imaginations of coders and hackers alike world-wide.
The last few posts were entirely about Rust. Like many, I view it as a monumental language that is changing programming for forever. One problem with Rust is that you can not just quickly throw something together. It creates solid software, but it stops you from hacking around. For some people Rust is a crown of thorns, just too damned hard to learn. Fortunately, now there are plenty of other interesting new languages to choose from.
Coming out of Google, Carbon was announced just recently. How clumsy of them to name it after an Apple MacOS API … They should just have named it Go++, although the language borrows many ideas straight out of Rust, as well. Carbon is a lot like Go with OOP added back in. It’s a shame really, because Go’s duck-typing is a lot nicer than class inheritance. Go’s unique parallellism with goroutines and channels also appear missing.
Carbon’s number one unique feature: interoperability with C++, which is said to be notoriously hard to implement due to name mangling and differing ABIs. With a company as big as Google behind it, there’s no doubt this language is going to make an impact. Google is basically telling everyone that the world needs to move on from C++. Even if Carbon bombs, it’s become awfully clear that C++ is well past its due date.
The big problem with Carbon is that the announcement was premature. The language is practically like a baby. It is unusable at this point, arguably it shouldn’t even have made this list. We spent too many words on it already, check back in a year or so?
Imagine Rust without borrow checker. That’s what Zig code looks like. Zig has some great ideas, it’s a pretty awesome systems programming language. It’s full of modern features like mutable variables vs. immutable constants, slices, nullable pointers, a system for error handling, builtin facilities for unit testing, generics, SIMD support, reflection, a customizable memory allocator, special keywords for async functions, compile time code execution, and confusing return loop expressions. The list of features just goes on and on, I’m sure I’ve left out a lot.
The only drawback is that in programming languages, less is more. Zig is unfortunately not as easy as it looks at first sight. My first impressions with Zig went something like this:
Me: print hello, world! Zig: (to stderr) "hello, world!" Me: That's to stderr. I want to print to stdout. Zig: "You can't do it". Me: But ... I want to print ... to stdout. Zig: "You can't do it. I print to stderr". Me: *googling for half an hour straight* Zig: "OK, you can do it, but it's complicated. You have to get a stdout writer and use that to implement your own print function". Me: Are you kidding me?! Zig: "All your codebase are belong to us".
Get past that, and Zig is awesome. I do think they took things too far; its creators seem to believe that more technical is more cool. And therefore Zig gets very technical. But who knows, Zig just might win the hearts of those who find Rust too hard.
The creator of Odin
stole from was heavily inspired by Jai.
It came forth from the “Handmade” community that do hardcore gamedev,
writing games from scratch. This type of coders frown upon OOP, are used
to doing manual memory management, and typically utilize a coding style
that uses a ton of global state.
The gamedev hackers don’t waste time on elegant code structures,
the only thing that matters is it that it runs, and that it runs fast.
I have to say, the syntax of
Jai Odin is pleasant to work
with. The language definition is not overly large, and people should be able
to fly in this language.
That said, the Pascal pointer syntax stabs me in the eye. Sorry, it’s
a personal thing.
Odin has many builtin types: math vectors, RGBA colors, matrices,
quaternions—gamedev, it shows. It could have been left to the
library and it would have been fine.
Struct methods are missing, forcing a very 1970s code style upon you despite being a modern language. That is archaic, and I’m not fond of such an old-fashioned style. I need my struct methods. (You know, I didn’t appreciate ‘em until they were gone..!)
I tried to do some Linux systems programming in Odin and got literally nowhere. That could easily be my fault, but I feel like the present APIs are all for gamedev, and lacking for other types of work. I read that the core library is a work in progress, and I should come back later and give Odin another chance.
Odin is kind of marvelous and I do want to like this language. If Odin stays in its gamedev corner however, then I fear for its future. Game developers will be switching en masse to Jai, iff it ever gets a public release.
The Nim crowd must be rolling over the floor laughing out loud at the Rust gang. Nim is Python-like, but it actually compiles to native binary code. It’s glorious. It looks so ridiculously easy that it’s almost hard to take seriously. But it really works, and it works really well.
Maybe it’s even too much script-like; for example, using “
echo” to print.
Nim’s most unique feature: it’s insensitive to
Someone can actually write a library in CamelCase and then you can call it
using snake_case. Genius! On the other hand, it breaks
in a large codebase. It’s an unusual choice, but man I wish Go had this;
personally I can’t stand CamelCasing in anything other than struct types.
Nowadays we only have luxury problems: there are too many options to choose from. Besides the pretty well-known Julia and Kotlin, here’s a couple of other interesting languages that deserve more attention:
- V (or Vlang)
- Peregrine (experimental alpha at the moment if you ask me)
And yeah, there is always Rust.