Having another look at Odin (Zig on hold)
When I went looking for the right language to explore some thinking around favouring single-machine performance in preference to complex distributed architectures, Zig hit the sweet spot both technically and philosophically. But I am now returning to have another look at Odin, the other contender on my short-list.
The Back Story
A couple of years back I developed a quick reaction solution to assess the data quality of geospatial time-series data. While the data volumes were modest in absolute terms (e.g., a few billion records), I felt the algorithmic complexity of the data processing best suited an imperative programming language. Java was already in the environment, and is a language I love working with, so that's what I used.
The performance of the solution was pleasing, and was at least comparable with an alternative data lake implementation built using SQL and running on a much larger distributed hardware configuration. In turn, this triggered quite a bit of deep thinking about how far such an approach could be pushed with more optimal tooling, including a programming language that was closer to the hardware and that allowed the programmer direct control over memory layout and management.
So I went looking at programming languages.
Why I Chose Zig
After a little bit of a search
performance
clean and simple
SIMD
philosophy – no chip on shoulder, avoidance of blanket AI, desire for open source
Why I am Having Another Look at Odin
While I deeply appreciate Zig and the ecosystem around it, and the resultant code and performance are noteworthy, I am finding myself hitting speed bumps each time I travel a path for the first time, or the first time in a while. And probably the standard library is that upon which I trip most often:
the documentation is patchy, often non-existent, and sometimes targeted more at understanding how or why more so than how to, so I am often using an Internet search for examples in place of documentation
through some combination of documentation and language visibility mechanisms, it is often difficult to unpickle what is callable API versus what is implementation (e.g., of the 20 functions on the documentation web page, perhaps only a couple are of any interest to me as a user of the library)
as a language targeted at low level system design, library coverage of higher-level functionality that I need for my use case (e.g., time zone aware dates and times) is limited and thus needs to come from third-party contributions
At times, it feels difficult to do simple things like write to the console. Again, I feel this isn't the fault of the language per se, but more so due to some combination of misalignment between the language objectives and my objectives, and the amount of time I have to devote to learning the language. But I keep coming back to ask myself if there is a way forward that offers less friction.