3 ms·

Don’t C++ and Rust still have the memory fragmentation issue, since they have to use an allocator at some point?

• tannhaeuser 7y ago
  Exactly. That's why I don't think close-to-metal languages are the way to go for most apps (as in "C is not a general-purpose language"), except the ones I listed, and probably some. I admire the Rust community's energy and persistence to create a new zero-overhead language, but, for me at least, they're ultimately falling victim to the idea that an app must be a single giant monolithic binary. C and Unix grew strong because of small little composable programs, where each program's memory was manageable enough in a way multithreaded, let alone async/evented server-like programs aren't (if they need dynamic memory at all). But ever since idk Java app servers? people have this idea that they're better at memory management than the kernel + MMU when that isn't clearly demontrated at all considering that eg. GC overhead isn't insignificant in long-running programs. What I'd rather like to see is bringing down process spawning overhead (response latency), or at least a rational discussion backed by benchmarks why everybody (except unikernel folks) blindly follows the big fat app server idea when, from the outset, a process-per-request model with memory/permission/resource isolation clearly looks much saner given service-oriented workloads and troubles in recent years (eg side-channel attacks, DOSing, leaks).
• deleted 7y ago
  [deleted]