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.
jbritton · 1h ago
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.
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.
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.