News for hackers. Stuff that matters.
Re:Some Thoughts on Zig by pcwalton on Thursday July 21, 2022 @11:35PM (#32188198)
The trouble here is the same problem that affects tons of static analyses: what do you do about higher order functions. I'm pretty skeptical that heap allocating every call to a function pointer/closure/virtual method is going to be fast enough.
Re:Some Thoughts on Zig by fancl20 on Friday July 22, 2022 @12:38AM (#32188577)
What do you mean by saying heap allocation? Do you mean syscall or libc? Zig has a extremely explicit requirement for any allocation. You can have a preallocated region of memory in the allocator for recursion and only move the needle for each “heap allocation”.
Re:Some Thoughts on Zig by pcwalton on Friday July 22, 2022 @02:39AM (#32189210)
Ah, I see, it's a split stack. Well, we experimented with those in Rust for Rust->C calls and they were not fast enough (also, they cause problems with debuggers and tooling). Perhaps if virtual calls are uncommon, though.

At that point I have to wonder what the advantage is over just using explicit checks for overflow on the machine stack though.

Re:Some Thoughts on Zig by Schroedingersat on Saturday July 23, 2022 @03:47AM (#32201288)
You're still forcing a mindset onto the language that isn't present.

It's not 'a split stack' or any other particular solution. You pass in an allocator and it does it whichever way your chose allocator picks.

The goal is to explore sections of design space you're completely ruling out from before you even start.