Hello everybody!
In my last Hive programming tutorial - which has been a while - I wrote an intro article about the Zig programming language, with the intent to write many more follow-up tutorials about Zig.
However, as Zig is still pretty new and developing as a language, I noticed that for quite some functionality Zig is "borrowing" from other languages (mostly C) via bindings to external modules. In and by itself that is not an issue for a language, especially considering how Zig aims to become "a better C" and can even function as a C (cross-) compiler on its own. On the other hand, when writing an extensive programming tutorial series about Zig (like I had planned to do) I noticed myself (in the draft stages of writing the Zig tutorials) often explaining C-specific language constructs, semantics and idioms.
Hence, while still writing concepts / drafts for the aforementioned follow-up Zig tutorials, I was venturing into other - somewhat similar - new (systems programming) languages, such as Odin, but also Go lang and Rust (and quite some more!) initially for R&D on how those languages handle certain functionality (which is an enormous territory ranging from cryptography to graphics and game engines and concurrency programming, foreign function interfaces/ external language interoperability etc. etc.)
Regarding Odin I came to the conclusion of it being in a similar stage (as a language) as Zig is, arguably. After very careful studying I came to the conclusion ( personal preference mostly) how much I like Odin's language syntax and semantics.
// Returns a Fibonacci sequence with a given length
fib :: proc(seqlen: int) -> (seq: [dynamic]int) {
a, b: int = 0, 1
for len(seq) < seqlen {
append(&seq, a)
a, b = b, a+b
}
return seq
}
There is so much to say about Odin, but just to give an example with this Fibonacci sequence generator I wrote in Odin, I think this summarize quite nicely some of the language specifics, for example:
proc()),seqlen),seq, which means there's no need to explicitly declare nor instantiate it in the function body),But .... Odin like Zig at the moment also often resorts to external ( mostly C and C++ bound) repositories, as the Odin language too is working towards a v.1.0 version. And as such I was wondering if writing an extensive Odin tutorial series wouldn't rather quickly (in a matter of 2 or 3 years speaking) get outdated as the language is still in a heavy state of flux and over time perhaps more "native" repositories would emerge instead of the current C-bindings.
Rust is still relatively young but a bit older as Zig and Odin (it began in 2006 iirc). Contrary to Zig and Odin, Rust seems to aim to be a better C++, focusing mostly on a rather unique approach to memory safety (with the infamous "borrow checker"). Rust is backed by Mozilla, where it also emerged from originally, which has probably contributed to steady community growth and therefore Rust has now surpassed the stages of needing to resort to external language bindings (in many areas) and now a large ecosystem of native Rust packages ( called "Crates" in Rust terminology) - extending the standard library - exists at Crates.io.
However, while Rust is a great language with immense potential it is also a Huge language with a steep and long learning curve; a lot can be said about Rust but not that it's simple to get into let alone master. So, as a consequence, I figured I'd need quite a lot of Rust tutorial to cover the basic language constructs before being able to get into interesting project tutorials.
And then there is Go, slightly younger than Rust (Go was founded in 2009), and backed by Google. Go more or less also (like Zig and Odin) aims to be a better C and be "simple", it's also the only language of the four discussed here which does not have manual memory management but instead resorts to using a Garbage Collector (GC). As such I used to be of the opinion ( perhaps wrongfully so!) that Go shouldn't be considered a "systems programming language" for using a Garbage Collector, but it should! Many game devs shrug at GC-languages for game development and other graphics intensive use cases, but I think that is a mistake, as game engine Ebiten and 2d graphics / drawing / UI engine Gio UI prove!
And I was digging deeper and deeper into the rabbit hole of modern systems programming languages, more and more I got convinced how nice and most probably undervalued the Go programming language is!
To name a few things:
So, I decided to (instead of the planned Zig tutorial series) instead write an extensive series (like I previously did with my Learn Python series) about Go!
Let's Go! ,
Thanks for reading and see you at the next post!