6 ms·

Hard Mode Rust (2022)

141 points by rrampage 2y ago

akshayshah 2y ago
It’s interesting that the author now works on TigerBeetle (written in Zig). As I understand it, TigerBeetle’s style guide leans heavily on this style of resource management.
- messe 2y ago
  Explicitly marking areas of code that allocate is a core part of idiomatic Zig, so that doesn't surprise me all that much.
- gizmondo 2y ago
  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 https://matklad.github.io/2023/03/26/zig-and-rust.html
throwaway2037 2y ago
The article starts with: > This criticism is aimed at RAII — the language-defining feature of C++, which was wholesale imported to Rust as well. > because allocating resources becomes easy, RAII encourages a sloppy attitude to resources Then lists 4x bullet points about why it is bad. I never once heard this criticism for RAII in C++. Am I missing something? Coming from C to C++, RAII was a godsend for me regarding resource clean-up.
- Hemospectrum 2y ago
  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 https://news.ycombinator.com/item?id=42291417
  - SleepyMyroslav 2y ago
    Thx for linked thread. It was an interesting read to me. I have got a feeling that the division comes from two different system programming folks. Hard realtime folks see unbounded time and uh-oh its fatal. On other side soft realtime folks ask about probabilities and profiling data and its relatively fine for them if probability is low enough. Where both of the camps would agree if number of effects is bound somehow.
- conradev 2y ago
  > 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 https://news.ycombinator.com/item?id=33637092
  - ladyanita22 2y ago
    I am happy that Rust defaults to the easier, saner, safer approach by default, but lets you bypass RAII if you want to do so.
    - conradev 2y ago
      Yeah, I agree. It makes sense and I'm glad that Drop is in no way guaranteed. I am excited for allocator-api to eventually stabilize, too!
- flohofwoe 2y ago
  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/EUqoIz2iFU4/m/kPZ5ZK0K3gEJ 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.
  - jpc0 2y ago
    > 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). Isn't it pretty common in gamedev to use bump allocators in a pool purely because of this. Actually isn't that pretty common in a lot of performance critical code because it is significantly more efficient? I feel like RAII doesn't cause this, RAII solves resource leaks but if you turn off you brain you are still going to have the same issue in C. I mean how common is it in C to have a END: or FREE: or CLEANUP: label with a goto in a code path. That also is an allocation and a free in a scope just like you would have in C++...
    - flohofwoe 2y ago
      > Isn't it pretty common in gamedev to use bump allocators Yes, but such allocators mostly only make sense when you can simply reset the entire allocator without having to call destruction or housekeeping code for each item, e.g RAII cleanup wouldn't help much for individual allocated items, at most to discard the entire allocator. But once you only have a few allocators instead of thousands of individual items to track, RAII isn't all that useful either since keeping track of a handful things is also trivial with manual memory management. I think it's mostly about RAII being so convenient that you stop thinking about memory management cost, garbage collectors have that exact same problem, they give you the illusion of a perfect memory system which you don't need to worry about. And then the cost slowly gets bigger and bigger until it can't be ignored anymore (e.g. I bet nobody on the Chrome team explicitly wanted a keystroke to make 25000 memory allocations, it just slowly grew under the hood unnoticed until somebody cared to look). Many codebases might never get to the point were automatic memory management becomes a problem, but when it becomes a problem then it's often too late to fix because that problem is smeared over the entire codebade.
- XorNot 2y ago
  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.
- GuB-42 2y ago
  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.
  - throwaway2037 2y ago
    > In language performance benchmarks, you often see C++ being slower than C. This is the first that I have ever seen such a statement. And, I am sure we could legitimately write exactly the opposite: <<you often see C being slower than C++>>. Not much being said here. As I understand, C++ template code can be much faster than equivalent code in C because the compiler has more metadata for optimisation. The classic case is C's qsort() vs C++'s sort(), where the C++ version is much faster due to compiler optimisation.
kelnos 2y ago
The criticism of RAII is a little odd to me. The author list four bullet points as to why RAII is bad, but I don't think I've ever found them to be an issue in practice. When I'm writing C (which of course does not have RAII), I rarely think all that deeply about how much I am allocating. But I also don't write C for embedded/constrained devices anymore.
- flohofwoe 2y ago
  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).
- eptcyka 2y ago
  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.
duped 2y ago
I usually like matklad's writings but I have to be overly dismissive for a change. This is a skill issue. C, C++, Rust, it doesn't matter - if you have a systems problem where you are concerned about resource constraints and you need to care about worst-case resource allocation, you must consider the worst case when you are designing the program. RAII does not solve this problem, it never did, and anyone who thinks it does needs to practice programming more. It is not "hard" to solve though. It's just another thing your compiler can't track and you need to be reasonably intelligent about. There are sections of a program that cannot tolerate resource exhaustion, for which you set some limit, which is then programmable in some way, which then uses some shared state to acquire and release things of which RAII may help. But you still must handle or otherwise report failures. This is a bread and butter architecture concern for systems programming and if you're not doing it, get good at it.
- flohofwoe 2y ago
  Just like writing memory safe code in C is a skill issue right? ;) (I write mostly C code myself, but I'm also not immune to f*cking up now and then even though I write code for decades now).
  - dapperdrake 2y ago
    ASCII NUL terminated strings and double free don’t sound quite the same as gauging hardware requirements. Either you need a certain amount of memory or you don’t.
  - writebetterc 2y ago
    You sure can write C which makes you less prone to making memory safety mistakes, yes. Knowing how to do that is a skill issue. As you say, sometimes our skills fail us, and that's where tooling comes in. ASan, borrow checker, whatever. There's a reason that a lot of Rust programmers find their programs filled with Arc<Mutex<T>>. That's because they didn't have the skills to write memory safe systems programs in the first place. To be clear, of course I'm also not immune to fucking up :-).
- dzaima 2y ago
tomsmeding 2y ago
I can't help but feel this is reintroducing some of the problems it claims to solve in working around the difficulties. * The fact that there is an `Oom` error that can be thrown means that there is no increase in reliability: you still don't know how much memory you're going to need, but now you have the added problem of asking the user for how much memory you're going to be using — which they are going to be guessing blindly on! * This is because the memory usage is not much more predictable than it would be in easy mode Rust. (Also that "mem.lem()/2" scratch space is kind of crappy; if you're going to do this, do it well. Perhaps in allocating the correct amount of scratch space, you end up with a dynamic allocator at the end of your memory. Does that sound like stack space at the start of memory and heap space at the end of memory? Yes, your programming language does that for you already, but built-in instead of bolted-on.) * Furthermore, the "easy mode" code uses lots of Box, but if you want you can get the benefits of RAII without all the boxes by allocating owned vectors scrupulously. Then you get the benefit of an ownership tracking system in the language's typesystem without having to `unsafe` your way to a half reimplementation of the same. You can get your performance without most of the mess. * Spaghetti can be avoided (if you so desire) in the same way as the previous point. What you do achieve is that at least you can test that Oom condition. Perhaps what you actually want is an allocator that allows for simulating a particular max heap size.
- Animats 2y ago
  > 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.
  - flohofwoe 2y ago
    That's why languages like Zig come with several specialized allocators implemented in the stdlib which can be plugged into any other code in the stdlib that needs to allocate memory. You can still implement your own allocator of course, but often there's one already in the stdlib that fits your need (especially also because allocators are stackable/composable).
feverzsj 2y ago
So, it's just arena allocator, which is still RAII.
WhereIsTheTruth 2y ago
C++ problem isn't just RAII, it's the language becomes an unreadable mess, just like this Rust code C++ and Rust share the same criticism - poor readability - poor code navigation - poor compilation speed I find it interesting how they call simplicity "hard mode", quite concerning
forrestthewoods 2y ago
Interesting conclusion. I recently tried something similar and gave up. The extra lifetimes are awful. Including in author’s post, imho. Rust sucks at arenas. I love Rust. But you have to embrace RAII spaghetti or you’re gonna have an awful, miserable time.
- queuebert 2y ago
  Fortran 77 common blocks are the GOATs of arena allocation.
kookamamie 2y ago
> Ray tracing is an embarrassingly parallel task Yet, most implementations do not consider SIMD parallelism, or they do it in a non-robust fashion, trusting the compiler to auto-vectorize.
witx 2y ago
These are some really weird arguments against RAII. First and foremost it is not only used for memory allocation. Second the fact that we have RAII doesn't mean it is used like "std::lock_guard" to acquire and free the resource in the same "lifetime", always. Actually in 10+ years of c++ that's like 1% of what I use RAII for The only point I agree with is the deallocation in batches being more efficient. > Lack of predictability. It usually is impossible to predict up-front how much resources will the program consume. Instead, resource-consumption is observed empirically. I really don´t understand this point.
siev 2y ago
Moving all allocations outside the library was also explored in [Minimalist C Libraries](https://nullprogram.com/blog/2018/06/10/ https://nullprogram.com/blog/2018/06/10/)
mplanchard 2y ago
(2022)
tialaramex 2y ago
Probably wants a (2022) acknowledgement that this is a blog post from 2022.
jokoon 2y ago
I know that the C++ syntax can be messy, but to me the rust syntax can reach above levels of complex and difficult to read. Maybe I should practice it a bit more.
deleted 2y ago
[deleted]
agentultra 2y ago
I think Haskell also pushes you in this direction. It gets super annoying to annotate every function with ‘IO’ and really difficult to test. Sure, you still have garbage collection but it’s generally for intermediate, short lived values if you follow this pattern of allocating resources in main and divvying them out to your pure code as needed. You can end up with some patterns that seem weird from an imperative point of view in order to keep ‘IO’ scoped to main, but it’s worth it in my experience. Update: missing word
purplesyringa 2y ago
> This… probably is the most sketchy part of the whole endeavor. It is `unsafe`, requires lifetimes casing, and I actually can’t get it past miri. But it should be fine, right? I just can't. If you're ignoring the UB checker, what are you even doing in Rust? I understand that "But it should be fine, right?" is sarcastic, but I don't understand why anyone would deliberately ignore core Rust features (applies both to RAII and opsem).
deleted 2y ago
[deleted]
nayuki 2y ago
> Hard Mode means that you split your program into std binary and #![no_std] no-alloc library. Only the small binary is allowed to directly ask OS for resources. For the library, all resources must be injected. In particular, to do memory allocation, the library receives a slice of bytes of a fixed size, and should use that for all storage. I did exactly this in my QR Code generator library, C port and second Rust port: https://github.com/nayuki/QR-Code-generator/blob/master/c/qrcodegen.h https://github.com/nayuki/QR-Code-generator/blob/master/c/qr... , https://github.com/nayuki/QR-Code-generator/blob/master/rust-no-heap/src/lib.rs https://github.com/nayuki/QR-Code-generator/blob/master/rust... Writing the Rust code felt way safer because the language took care of enforcing rules about borrowing parts of the buffer.
jpc0 2y ago
> It’s on the caller to explicitly implement a concurrent queue to distributed specific work items The threadpool is usually the easy part of concurrent algorithm's, with the concurrent queue being one of the hardest to implement in a performant manner. The is a "draw the rest of the owl" moment...

141 points by rrampage 2y ago

It’s interesting that the author now works on TigerBeetle (written in Zig). As I understand it, TigerBeetle’s style guide leans heavily on this style of resource management.

messe 2y ago
Explicitly marking areas of code that allocate is a core part of idiomatic Zig, so that doesn't surprise me all that much.
gizmondo 2y ago
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 https://matklad.github.io/2023/03/26/zig-and-rust.html

throwaway2037 2y ago

The article starts with: > This criticism is aimed at RAII — the language-defining feature of C++, which was wholesale imported to Rust as well. > because allocating resources becomes easy, RAII encourages a sloppy attitude to resources Then lists 4x bullet points about why it is bad. I never once heard this criticism for RAII in C++. Am I missing something? Coming from C to C++, RAII was a godsend for me regarding resource clean-up.

Hemospectrum 2y ago
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 https://news.ycombinator.com/item?id=42291417
- SleepyMyroslav 2y ago
  Thx for linked thread. It was an interesting read to me. I have got a feeling that the division comes from two different system programming folks. Hard realtime folks see unbounded time and uh-oh its fatal. On other side soft realtime folks ask about probabilities and profiling data and its relatively fine for them if probability is low enough. Where both of the camps would agree if number of effects is bound somehow.
conradev 2y ago
> 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 https://news.ycombinator.com/item?id=33637092
- ladyanita22 2y ago
  I am happy that Rust defaults to the easier, saner, safer approach by default, but lets you bypass RAII if you want to do so.
  - conradev 2y ago
    Yeah, I agree. It makes sense and I'm glad that Drop is in no way guaranteed. I am excited for allocator-api to eventually stabilize, too!
flohofwoe 2y ago
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/EUqoIz2iFU4/m/kPZ5ZK0K3gEJ 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.
- jpc0 2y ago
  > 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). Isn't it pretty common in gamedev to use bump allocators in a pool purely because of this. Actually isn't that pretty common in a lot of performance critical code because it is significantly more efficient? I feel like RAII doesn't cause this, RAII solves resource leaks but if you turn off you brain you are still going to have the same issue in C. I mean how common is it in C to have a END: or FREE: or CLEANUP: label with a goto in a code path. That also is an allocation and a free in a scope just like you would have in C++...
  - flohofwoe 2y ago
    > Isn't it pretty common in gamedev to use bump allocators Yes, but such allocators mostly only make sense when you can simply reset the entire allocator without having to call destruction or housekeeping code for each item, e.g RAII cleanup wouldn't help much for individual allocated items, at most to discard the entire allocator. But once you only have a few allocators instead of thousands of individual items to track, RAII isn't all that useful either since keeping track of a handful things is also trivial with manual memory management. I think it's mostly about RAII being so convenient that you stop thinking about memory management cost, garbage collectors have that exact same problem, they give you the illusion of a perfect memory system which you don't need to worry about. And then the cost slowly gets bigger and bigger until it can't be ignored anymore (e.g. I bet nobody on the Chrome team explicitly wanted a keystroke to make 25000 memory allocations, it just slowly grew under the hood unnoticed until somebody cared to look). Many codebases might never get to the point were automatic memory management becomes a problem, but when it becomes a problem then it's often too late to fix because that problem is smeared over the entire codebade.
XorNot 2y ago
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.
GuB-42 2y ago
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.
- throwaway2037 2y ago
  > In language performance benchmarks, you often see C++ being slower than C. This is the first that I have ever seen such a statement. And, I am sure we could legitimately write exactly the opposite: <<you often see C being slower than C++>>. Not much being said here. As I understand, C++ template code can be much faster than equivalent code in C because the compiler has more metadata for optimisation. The classic case is C's qsort() vs C++'s sort(), where the C++ version is much faster due to compiler optimisation.

kelnos 2y ago

The criticism of RAII is a little odd to me. The author list four bullet points as to why RAII is bad, but I don't think I've ever found them to be an issue in practice. When I'm writing C (which of course does not have RAII), I rarely think all that deeply about how much I am allocating. But I also don't write C for embedded/constrained devices anymore.

flohofwoe 2y ago
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).
eptcyka 2y ago
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.

duped 2y ago

I usually like matklad's writings but I have to be overly dismissive for a change. This is a skill issue. C, C++, Rust, it doesn't matter - if you have a systems problem where you are concerned about resource constraints and you need to care about worst-case resource allocation, you must consider the worst case when you are designing the program. RAII does not solve this problem, it never did, and anyone who thinks it does needs to practice programming more. It is not "hard" to solve though. It's just another thing your compiler can't track and you need to be reasonably intelligent about. There are sections of a program that cannot tolerate resource exhaustion, for which you set some limit, which is then programmable in some way, which then uses some shared state to acquire and release things of which RAII may help. But you still must handle or otherwise report failures. This is a bread and butter architecture concern for systems programming and if you're not doing it, get good at it.

flohofwoe 2y ago
Just like writing memory safe code in C is a skill issue right? ;) (I write mostly C code myself, but I'm also not immune to f*cking up now and then even though I write code for decades now).
- dapperdrake 2y ago
  ASCII NUL terminated strings and double free don’t sound quite the same as gauging hardware requirements. Either you need a certain amount of memory or you don’t.
- writebetterc 2y ago
  You sure can write C which makes you less prone to making memory safety mistakes, yes. Knowing how to do that is a skill issue. As you say, sometimes our skills fail us, and that's where tooling comes in. ASan, borrow checker, whatever. There's a reason that a lot of Rust programmers find their programs filled with Arc<Mutex<T>>. That's because they didn't have the skills to write memory safe systems programs in the first place. To be clear, of course I'm also not immune to fucking up :-).
dzaima 2y ago

tomsmeding 2y ago

I can't help but feel this is reintroducing some of the problems it claims to solve in working around the difficulties. * The fact that there is an `Oom` error that can be thrown means that there is no increase in reliability: you still don't know how much memory you're going to need, but now you have the added problem of asking the user for how much memory you're going to be using — which they are going to be guessing blindly on! * This is because the memory usage is not much more predictable than it would be in easy mode Rust. (Also that "mem.lem()/2" scratch space is kind of crappy; if you're going to do this, do it well. Perhaps in allocating the correct amount of scratch space, you end up with a dynamic allocator at the end of your memory. Does that sound like stack space at the start of memory and heap space at the end of memory? Yes, your programming language does that for you already, but built-in instead of bolted-on.) * Furthermore, the "easy mode" code uses lots of Box, but if you want you can get the benefits of RAII without all the boxes by allocating owned vectors scrupulously. Then you get the benefit of an ownership tracking system in the language's typesystem without having to `unsafe` your way to a half reimplementation of the same. You can get your performance without most of the mess. * Spaghetti can be avoided (if you so desire) in the same way as the previous point. What you do achieve is that at least you can test that Oom condition. Perhaps what you actually want is an allocator that allows for simulating a particular max heap size.

Animats 2y ago
> 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.
- flohofwoe 2y ago
  That's why languages like Zig come with several specialized allocators implemented in the stdlib which can be plugged into any other code in the stdlib that needs to allocate memory. You can still implement your own allocator of course, but often there's one already in the stdlib that fits your need (especially also because allocators are stackable/composable).

feverzsj 2y ago

So, it's just arena allocator, which is still RAII.

WhereIsTheTruth 2y ago

C++ problem isn't just RAII, it's the language becomes an unreadable mess, just like this Rust code C++ and Rust share the same criticism - poor readability - poor code navigation - poor compilation speed I find it interesting how they call simplicity "hard mode", quite concerning

forrestthewoods 2y ago

Interesting conclusion. I recently tried something similar and gave up. The extra lifetimes are awful. Including in author’s post, imho. Rust sucks at arenas. I love Rust. But you have to embrace RAII spaghetti or you’re gonna have an awful, miserable time.

queuebert 2y ago
Fortran 77 common blocks are the GOATs of arena allocation.

kookamamie 2y ago

> Ray tracing is an embarrassingly parallel task Yet, most implementations do not consider SIMD parallelism, or they do it in a non-robust fashion, trusting the compiler to auto-vectorize.

witx 2y ago

These are some really weird arguments against RAII. First and foremost it is not only used for memory allocation. Second the fact that we have RAII doesn't mean it is used like "std::lock_guard" to acquire and free the resource in the same "lifetime", always. Actually in 10+ years of c++ that's like 1% of what I use RAII for The only point I agree with is the deallocation in batches being more efficient. > Lack of predictability. It usually is impossible to predict up-front how much resources will the program consume. Instead, resource-consumption is observed empirically. I really don´t understand this point.

siev 2y ago

Moving all allocations outside the library was also explored in [Minimalist C Libraries](https://nullprogram.com/blog/2018/06/10/ https://nullprogram.com/blog/2018/06/10/)

mplanchard 2y ago

(2022)

tialaramex 2y ago

Probably wants a (2022) acknowledgement that this is a blog post from 2022.

jokoon 2y ago

I know that the C++ syntax can be messy, but to me the rust syntax can reach above levels of complex and difficult to read. Maybe I should practice it a bit more.

deleted 2y ago

[deleted]

agentultra 2y ago

I think Haskell also pushes you in this direction. It gets super annoying to annotate every function with ‘IO’ and really difficult to test. Sure, you still have garbage collection but it’s generally for intermediate, short lived values if you follow this pattern of allocating resources in main and divvying them out to your pure code as needed. You can end up with some patterns that seem weird from an imperative point of view in order to keep ‘IO’ scoped to main, but it’s worth it in my experience. Update: missing word

purplesyringa 2y ago

> This… probably is the most sketchy part of the whole endeavor. It is `unsafe`, requires lifetimes casing, and I actually can’t get it past miri. But it should be fine, right? I just can't. If you're ignoring the UB checker, what are you even doing in Rust? I understand that "But it should be fine, right?" is sarcastic, but I don't understand why anyone would deliberately ignore core Rust features (applies both to RAII and opsem).

deleted 2y ago

[deleted]

nayuki 2y ago

> Hard Mode means that you split your program into std binary and #![no_std] no-alloc library. Only the small binary is allowed to directly ask OS for resources. For the library, all resources must be injected. In particular, to do memory allocation, the library receives a slice of bytes of a fixed size, and should use that for all storage. I did exactly this in my QR Code generator library, C port and second Rust port: https://github.com/nayuki/QR-Code-generator/blob/master/c/qrcodegen.h https://github.com/nayuki/QR-Code-generator/blob/master/c/qr... , https://github.com/nayuki/QR-Code-generator/blob/master/rust-no-heap/src/lib.rs https://github.com/nayuki/QR-Code-generator/blob/master/rust... Writing the Rust code felt way safer because the language took care of enforcing rules about borrowing parts of the buffer.

jpc0 2y ago

> It’s on the caller to explicitly implement a concurrent queue to distributed specific work items The threadpool is usually the easy part of concurrent algorithm's, with the concurrent queue being one of the hardest to implement in a performant manner. The is a "draw the rest of the owl" moment...