This is actually what first drew me to zig. Most people talk about error handling, but the explicit allocator handling and making choosing an allocator a deliberate consideration has pushed me to better coding habits in general. I don't think it is possible or practical to completely abandon heap-allocated memory, but explicitly choosing between allocation types and styles that most precisely fit a job has great potential for meeting that spirit.

Most stack oriented languages also have a heap.

the stack is just a bump allocator. the unique thing about stack-only languages is lifetime management, not really how they allocate.

That's a great reference, thanks!

Disagree, I found malloc source useful, and writing a toy allocator especially useful because you learn about the brk() syscall which is a great breadcrumb into kernel land and a great bridge to connect the memory mapping lessons from computer architecture with application code.

    %define HEAP_SIZE (4 * 1024 * 1024 * 1024)

    .section bss
    ;;
    ;; Two heaps so we can flip-flop between them
    ;;
    heap_a:
        resb HEAP_SIZE
    heap_a_end:
    heap_b:
        resb HEAP_SIZE
    heap_b_end:

Malloc needs the kernel to obtain memory, but in any reasonable implementation (you do not want to make a syscall for every malloc and free) is mostly user space, and studying that will tell you a lot about how your malloc works.

It's a consumer market scarcity. Since you're supposed to run everything on rented hardware, own nothing and be happy, I'd expect the malloc to be the right place to invest into once it is IPO.