Hello everybody! How is everybody doing?
I'm back. Again...
It has most certainly been quite a while since I last posted here, although I have been reading / lurking most every single day, and even then I didn't push through on my plans to publish entire series of development tutorials on various languages.
I mentioned Rust, Odin, Go, Zig, and quite frankly: I like all of them. A lot. Just like I am also very fond of JavaScript, Python, Lua, GDscript and GLSL/HLSL/VLSL ("shaders"). I've also coded in C, C++, Dart (and Flutter), Bash, OCaml and Lisp - and spent way too much time on PHP - and this is not even counting HTML, CSS, DSLs or other non-turing complete computer languages. And also I did indeed spend quit some time preparing those tutorials, locally, without publishing them, yet, and I've written quite a lot. I like developing as much as I like writing and teaching about it, and in doing so I set my standards quite high and keep adding and improving until I think "now it's good enough". And that moment might never come. I might be suffering from a touch of "perfectionism" perhaps....
So, I got up early, decided to just write this blog post right here and now to "get going again" and post it too. Bam, jonguh!
I've noticed a recurring theme thinking about various languages and their ecosystems: the more languages I've studied, the more cool stuff I've seen here or there that I appreciate a lot but don't find - yet - in language (ecosystem) X.
For example, here is a super simple listing with a fib() procedure (proc) in the Odin language that returns a (dynamic) array of length seqlen containing consecutive Fibonacci numbers (I've also used the same example in my Intro post of my original Learn Python Series):
package main
import "core:fmt"
fib :: proc(seqlen: int) -> (seq: [dynamic]int) {
a, b := 0, 1
for len(seq) < seqlen {
append(&seq, a)
a, b = b, a + b
}
return seq
}
main :: proc() {
seqlen:= 20
fib_seq:= fib(seqlen)
fmt.printf("fib(%d): %v\n", seqlen, fib_seq)
// which will print:
// fib(20): [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181]
}
I could write an entire book - which would then probably also suffer from perfection paralysis and never get published ;-) - about what I love about this tiny bit of code, but the fact I just wrote this top-of-mind without thinking what or how and enjoy doing it says it all perhaps. A few concrete highlights then, about what I love about Odin are named return variables (seq (short for "sequence") is already defined and zero-instantiated in the procedure signature without the need to declare it inside the body), and a second example is the fact that Odin is strictly procedural (which is also the reason Odin has "procedures" rather than "functions"); other languages (for example Java, Python) often have classes that contain both data and methods to work on that data, and there are languages (besides Odin, there's Go, Rust, Zig) that have the concept of a struct (short for "structure") which is a container to hold various sorts of data. However in those other languages a struct can still implement functions (then called "methods") specifically intended for that data type. In my opinion this needlessly complicates matters of what is the difference between a "function" and a "method". Odin remains faithful to its principles: data is data and does not contain methods, not even as syntactic sugar like in Zig and Go. In Odin, if a specific procedure is designed to work with a specific type of struct, (a reference to) that struct needs to be passed into the proc as an argument, instead of the other way around. I like that consistency. It's simple, it's clear, it does what it says it does.
The creator of the Odin language (Bill Hall, aka "Ginger Bill") has done, IMO, an exceptionally good job of language design. One can argue about syntax, Odin's syntax is a bit of a mixture of Pascal and Go, which in the case of Odin I absolutely love but others might be used to and/or prefer something else entirely. But Odin's syntax is consistent. Everything about Odin is consistent. And the syntax aside, there's much more to language design that Odin has absolutely nailed. I'll discuss that another time (hopefully).
But if I love the Odin language that much, why not just stick with Odin for everything and call it a day?
The main reason for this is that Odin in its current pre-1.0 shape and form cannot yet do everything as good as some other languages and their library ecosystem can. I hope it will get there. But I'm not so sure of that, and I really hope I'm wrong in that because I want Odin to succeed. For example, can Odin do networking? Yes of course it can, but as of today in Odin's standard libary there is not yet an included http client nor server for example. There are a few community libraries available, most notably https://github.com/laytan/odin-http , but this is very much a work in progress and right here and now this repo is not compatible with the latest released Odin version (odin version dev-2025-06) that ships with Homebrew on MacOS as of today. Or course I can make it work by simply installing the latest Odin nightly build, or alternatively rewrite just one line of code that causes Laytan's odin-http to not compile (on my machine) because of it using one Odin-lang proc that is not yet included in my Homebrew executable. But it requires a bit of hacking around. I don't always have time for that when I just need to deploy a quick working solution that I can ship.
Odin doesn't yet have async-await. You need a websocket implementation to continuously update the Binance order books for HIVEUSDT? Then good luck writing it yourself. A plug-n-play Odin connector for MongoDB: happy Codin' in Odin.
When your main goal is to hand-code (2d) games using Raylib then arguably Odin is the GoTo language, perhaps even for absolute beginners. But if your goal is a cross-platform (including mobile) online dating web service only written in Odin, then I wish you a happy 2026 and 2027 right now because you'll be quite busy for a while. Its ecosystem it not quite there, nor is its tooling.
On the contrary, a language that does have a solution for every problem you can think of is the Rust programming language.
I love (almost all) software written in Rust. It's usually blazing fast. Lightweight. And stable as a rock. I have a Love-Hate relationship with the Rust compiler because man is it STRICT in what you can and mostly cannot do, but at the same time when something is wrong or could be improved it absolutely pinpoints with incredible precision and eloquence and clarity where, what and how you need to improve your code. The Rust cargo toolchain and package manager is in my opinion the best ever written by mankind: in 19/20 times you can just go to Github, git clone some Rust repo, cd into said cloned folder and type cargo run: it just works (although more often than not you can enjoy one or a few cups of coffee while compiling often HUNDREDS of dependencies: Rust's compiler is pretty slow, mostly because of how agressively it optimizes which takes time).
Also, when you're looking for some crate (library, framework in Rust) to include in your project, just go to https://crates.io/ and yank via cargo add <cratename> into your local Cargo.toml, and if you want to browse its documentation just do so in https://docs.rs/ in the next browser tab.
Rust's ecosystem and stability is absolutely phenomenal. There's a (great!) solution for literally everything.
But if I love the Rust language that much, why not just stick with Rust for everything and call it a day?
... Because I have to admit thus far I have not really enjoyed writing Rust: I love the software that Rust produces, I love its toolchain, but the language itself sometimes often drives me bonkers! It took me a while to pinpoint why that is so, but I can now understand and explain myself in this assessment, it's just two factors:
-1- Rust's ownership-borrow checker implementation, while highly innovative on the one hand, more often than not needlessly complicates matters, where you need to jump through hoops to do something that you can effortlessly do in just about any other programming language but not Rust, and the solution to that then leads to extremely complex and verbose code that can feel "alien". When I read complex code other Rust devs wrote or even something I wrote myself more than 6 months ago, very often I need to read and re-read and re-re-read to understand what's happening and how something works. This causes headaches and slows me down.
-2- (Presumably?) in an attempt to go easier on the eyes, Rust's macro-system is both a blessing and a curse. There exists this great Rust cross-platform UI library Dioxus that has spent a good deal of effort to make coding in Dioxus as user-friendly as possible. You can just write for example:
#[component]
fn App() -> Element {
rsx! {
div { id: "greeting",
h1 { "Hello, World! ðŸŒ" }
}
div { id: "buttons",
button { id: "decr_btn", "-" }
button { id: "clear_btn", "c" }
button { id: "incr_btn", "+" }
}
}
}
... and you're off to the races! But notice the two macros rsx! and #[component]. You tell me what they do and how the function exactly, I'll wait... Rust's macro-system is extremely powerful in abstracting-away complexity, to hide it, including the borrow-ownership issues I described under -1- but that is not "simplifying". Odin, Zig and Go are all prime examples of a simple language: that is not the same thing as easy. Because of Rust's macro-system certain libraries can become user-friendly, perhaps easier to work with - which is great - but at the cost of adding "magic" and "complexity". Or to put it differently, macros make WRITING Rust easier but READING and understanding the exact inner workings of a Rust program f*cking hard. Rust code that I wrote 2 years ago will probably work just fine if I compile the exact same code on a new computer 5 years in the future from now, but if I try to read and understand it then I am in for a hard time and perhaps failure.
I've only covered Rust and Odin here, but I can do the same for the following languages (I know, I know, I am cutting corners here and just about everything is up for debate, but this is my opinion):
@cImport() and cross-compilation (zig cc ...), total control, Spartan memory management, breaking changes everywhere per compiler version (I often have troubles compiling my own code I wrote just 6 months ago in a previous version);etc. etc. etc.
These (quick, dirty, incomplete, opiniated) languages comparisons bring forward a developer dilemma: in which language do I want to specialize? Should I specialize even? And if so, does that mean specialising in a language, or in a programming niche, or both?
It's not economically viable to do everything under the sun in -for example- Odin or Zig right now, but does that mean I should ignore them until it's more "mainstream" or should I only use it for the parts that are "production-ready" (and enjoyable)?
Something that's often overlooked is that learning and then mastering a programming language is a Herculean undertaking: you need to learn the language itself (which in the case of Rust is huge and for Lua and Odin and Go is doable in a reasonable timespan), but then you need to work with other people's code too and each ecosystem is huge. It takes time, it takes a great deal of effort and energy, and there's more to do in life than just programming.
Like with my planned, aspired, tutorials series, when you know how eloquent and fast you can write something AND understand it ... 5 years later even, in one language, automatically makes you compare that to your own personal performance of "being productive", fast, fluent and eloquent in another language.
Perhaps I should just accept that I am multi-interested in diverse projects and languages and just go with the flow of what I am interested in doing right there and then, and break free from my drive to perfection?
A "devlog"! ,
And regarding writing about it, well here you have it: a format (this "dev log") that I enjoy writing top-of-mind (I hope you enjoyed reading it too!) and that is independent of the following or previous episodes. So let's see if my writer's inspiration keeps flowing in more (semi- / un-)structured devlog episodes!
Thanks for reading!