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 and throughput requirements of the task 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, being at least comparable with an alternative data lake implementation built using SQL and running on a much larger distributed hardware configuration. In fact, please enough to trigger quite a bit of deep thinking about how far the actual code running on a single box 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, and the usual contenders emerged as matching my requirements of being compiled, having no garbage collection, being close to the hardware, and having some modern language features: C, C++, Odin, Rust, Swift and Zig.

To cut a long story short I discounted C as having insufficient native language features to pique my interest, and C++ and Rust as being too complex ((https://lightpanda.io/blog/posts/why-we-built-lightpanda-in-zig([I'm just not smart enough]).

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

re-wilding the Internet

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 entirely 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.

#Odin #Zig