7,578 karma · joined March 25, 2007
Berkeley, California
Email: jey#kottalam!net
I think the idea is that a small program can organize its allocations and data structures to minimize number of calls to malloc, e.g. with preallocated workspace structs, or slab allocation, and similar approaches. But as a program gets bigger, there's a pressure to have looser coupling, to have subsystems with simple convenient APIs which leads to them doing on-demand malloc calls internally, rather than having consumers pre-allocate their needed workspace. Because that kind of workspace management results in more complex APIs and more burden on the consumer.
That said, I don't really believe it either, at least for the kind of codebase where it would matter (scientific computing, in-memory DB server, etc). A codebase that places an emphasis on minimizing heap operations in hot codepaths can do so by consistently using workspaces and allocation-avoiding APIs. I don't think it's so difficult really, but it does take a conscious design decision to do so. But writing something like a web browser in this way could be annoying due to most data having wildly variable sizes, and zig's arena concept would be very handy -- but rust has crates like bumpalo for that purpose.
My personal mantra: "Think in FORTRAN, code in Rust/Julia/C++". But I'm mostly working on HPC-style code where I don't have to do with wildly varying input or output sizes.
It's nice to have this perspective validated by someone like Serre! I felt like I was missing something when I first encountered that formalism. In fact, all of my introductory calculus classes sucked and turned me off of math for a few years.
This is a feature, not a bug. That it's using your platform-specific emojis makes it easier to scan, since it's the ideograms you are already accustomed to. Much faster to scan familiar symbols than to read each section heading serially.
EDIT: I retract my claim. I didn't realize this had servo as a dependency.