Instinctually I’m bothered by passing an allocator to everything. LISP’s dynamic variables spring to mind. One could set an arena allocator at the top of a loop in a dynamic variable and then everything inside the loop would use that allocator. The bottom of the loop could free everything. Although I do really like knowing if something might call an allocator, perhaps a function specifier to indicate it allocates.
Although I’m intrigued by another idea I haven’t thought through. Haskell requires all function side effects to essentially propagate a description of the side effect up to main() where Haskell executes the side effect.
There is also the idea of imperative shell, functional core that I don’t fully grasp. In any case perhaps all side effects should execute at the top level or maybe in a parallel environment and here passing an allocator would not be so onerous.
The ease of using Odin over Zig for Raylib was an interesting contrast that I hadn’t reflected on myself. I tried to do things well with C3, but it might be hard to beat Odin on that particular point.
I just wonder how well it will work long term with update cycles and such. Zig and C3’s decentralized model seems easier for handling frequently updating libraries.
I disagree on many points the article makes, but it is well written and lays out its arguments well.
One example - I prefer the named fields of Zig over Odin's use of positional fields. Zig's syntax is the more popular one as of late, heck even C has named struct member initialization.
IMHO Positional is just asking for trouble. Yes it works fine for game programming, and not having to specify x and y thousands of times in a code base is nice, but for general purpose languages where a struct can have a dozen+ fields to init, positional assignment is how bugs are made.
You can simply offer a function to create an object using positional arguments if you want that
C gives either, I think that is the true with Odin as well, it certainly is for C3. I was assuming Zig allowed both. Is this another one of Zig being strict with ”only one way”?
I stumbled across Zig by a reference to it as part of the Bun (JS engine) documentation.
I didn't find the Zig language benefits sufficiently compelling to learn yet another opinionated language.
Since much of my work is with embedded and bespoke systems, I did find the Zig cc front-end to LLVM convenient. Maybe it's because I haven't sufficiently mastered Clang for cross-compilation.
I like the try/catch of Zig. It is innovative.
Moreover Zig is a research playground. Ideas will find their way to D/Nim.
Zig CC is another innovation.
The compile time is also a great experiment.
It brings a lot to the table.
May not be a total C replacement, but it is an improvement and lots of C code, can be written in Zig. Lots of people can be introduced to Systems Programming with Zig. For Low Level coding, have you heard of FASM? Better than C in my opinion.