Earlier quoted context omitted.
I sometimes wonder if full GC is really worth it. For a lot of applications some compile time analysis + refcounting is close enough, and for some others arenas (per frame rendered, per request served, etc) are as fast as a GC to allocate and faster than malloc to free. Could we make the rest a compile error and save most people most of the time a lot of pain?
GC is worth it. What you're proposing is a false economy. In addition to lifetime management, GC gives you compaction, pointer compression, and fast bump-pointer allocation that doesn't depend on being able to represent your lifetimes as nested arenas. Modern GC is excellent. Replacing it with manual allocation isn't better, even with guardrails: reference counting is expensive, atomic reference counting doubly so, a…
Re: Bun has an open PR adding shared-memory threads to JavaScriptCore
#171How modern is modern, and who's implemented it? In recent memory (last decade or so) I've had to work around the GC by doing exactly what you describe with arrays as well as off-heap storage to avoid memory footprint and pause issues across Java, Go, and Javascript. Writing something like say Objective C (with its refcounting, autorelease pools, etc) seemed pretty productive, had predictable behavior, etc. I follow GC development a bit, and often cite some of the stuff Gil Tene has written as an example of clear technical writing and thinking, but I'm not convinced GC is that universally good. Rust's approach has a high ergonomics cost but the Swift people seem to get by.