Hard Mode Rust (2022)

> I can't help but feel this is reintroducing some of the problems it claims to solve in working around the difficulties.

When I read "So we do need to write our own allocator", I winced. Almost every time I've had to hunt down a hard bug in a Rust crate, one that requires a debugger, it turns out to be someone who wrote their own unsafe allocator and botched the job.

It's quite common knowledge in the gamedev world (at least the part that writes C++ code, the other parts that uses C# or JS has roughly the same problem, just caused by unpredictable GC behaviour).

Towards the end of the 90s, game development transitioned from C to C++, and was also infected by the almighty OOP brain virus. The result was often code which allocated each tiny object on the heap and managed object lifetime through smart pointers (often shared pointers for everything). Then deep into development after a million lines of code there's 'suddenly' thousands of tiny alloc/frees per frame and all over the codebase but hidden from view because the free happens implicitly via RAII - and I have to admit in shame that I was actively contributing to this code style in my youth before the quite obvious realization (supported by hard profiling data) that automatic memory management isn't free ;)

Also the infamous '25k allocs per keystroke' in Chrome because of sloppy std::string usage:

https://groups.google.com/a/chromium.org/g/chromium-dev/c/EU...

Apart from performance, the other problem is debuggability. If you have a lot of 'memory allocation noise' to sift though in the memory debugger, it's hard to find the one allocation that causes problems.

In language performance benchmarks, you often see C++ being slower than C. Well, that's a big part of the reason. There is no real reason for C++ to be slower since you can just write C code in C++, with maybe a few details like "restrict" that are not even used that much.

The big reason is that RAII encourage fine grained resource allocation and deallocaion, while explicit malloc() and free() will encourage batch allocation and deallocation, in-place modification, and reuse of previously allocated buffers, which are more efficient.

The part about "out of memory" situations is usually not of concern on a PC, memory is plentiful and the OS will manage the situation for you, which may include killing the process in a way you can't do much about. But on embedded systems, it matters.

Often, you won't hear these criticisms. C programmers are not the most vocal about programming languages, the opposite of Rust programmers I would say. I guess that's a cultural thing, with C being simple and stable. C++ programmers are more vocal, but most are happy about RAII, so they won't complain, I can see game developers as an exception though.

> Poor performance. Usually, it is significantly more efficient to allocate and free resources in batches.

This one is big. It is a lot of accounting work to individually allocate and deallocate a lot of objects.

The Zig approach is to force you to decide on and write all of your allocation and deallocation code, which I found leads to more performant code almost by default – Rust is explicitly leaving that on the table. C obviously works the same way, but doesn't have an arena allocator in the standard library.

Re: C++ vs Rust, it might be more of a pain in Rust because of this: https://news.ycombinator.com/item?id=33637092

You're most likely to hear it from kernel programmers and Go/Zig/Odin advocates, but it rarely comes up as a criticism of C++ in particular. Perhaps that's because RAII is merely "distasteful" in that cohort, whereas there are many other qualities of C++ that might be considered total showstoppers for adoption before matters of taste are ever on the table.

There was an HN thread a few months ago[0] debating whether RAII is reason enough to disqualify Rust as a systems language, with some strong opinions in both directions.

[0]: https://news.ycombinator.com/item?id=42291417

The "hard mode" described in this article covers an issue I do keep running into with Golang funnily enough: I really hate the global imports, and I really want to just use dependency injection for things like OS-level syscalls...which is really what's happening here largely.

So it's interesting to see something very similar crop up here in a different language and domain: throw a true barrier down on when and how your code can request resources, as an explicit acknowledgement that the usage of them is a significant thing.

Allocating in the hot path degrades the performance unless you're using an allocator that is designed for that and you are hand-tuning to not need to allocate more memory. This can be a game or anything with a hot path you care about, doesn't have to be deployed on an embedded device.

It mostly becomes a problem at scale when you need to juggle tens or hundreds of thousands of 'objects' with unpredictable lifetimes and complex interrelationships. The cases where I have seen granular memory allocation become a problem were mostly game code bases which started small and simple (e.g. a programmer implemented a new system with let's say a hundred items to handle in mind, but for one or another reason, 3 years later that system needs to handle tens of thousands of items).

Here the author did a small comparison between the languages in the context of TigerBeetle: https://matklad.github.io/2023/03/26/zig-and-rust.html

Explicitly marking areas of code that allocate is a core part of idiomatic Zig, so that doesn't surprise me all that much.