[PaulDavisThe1st]

A perfect demonstration of how many of harder problems we face writing (especially non-browser-based) software are in fact not addressed by language changes.

The concept of memory that is allocated by a thread and can only be deallocated by that thread is useful and valid, but as TFA demonstrates, can also cause problems if you're not careful with your overall architecture. If the language you're using even allows you to use this concept, it almost certainly will not protect you from having to get the architecture corect.

[the-smug-one]

I think Rust's language design is in part to blame, as it does not force the programmer to think sufficiently of the layout of the memory, instead allowing them to defer to a "global allocator".

[PaulDavisThe1st]

This identical problem could easily occur in a C or C++ codebase.

[the-smug-one]

I never said that C and C++ doesn't suffer from the same design problem? I'd say that Zig is the best in class here, typically forcing you to pass along an allocator to each data structure. C is a bit better than C++, as it uses an allocator explicitly, while C++ relies on new/delete with a default impl calling malloc/free.

Still a language design issue: C++ and Rust doesn't put allocation concerns front and center, when they very much are. Not encouraging thinking about these things is very bad for systems languages.

[PaulDavisThe1st]

This issue isn't really about per-structure allocators at all.

It's about the idea that you are using per-thread allocators, and one of your threads allocates a lot of memory, then goes to sleep for a long time.

Per-thread allocators are orthogonal to per-structure allocators.

[the-smug-one]

I think you misunderstand what I'm saying, as what I'm describing allows for per-thread allocators.