I can't help but feel this is reintroducing some of the problems it claims to solve in working around the difficulties.<p>* 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!<p>* 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 <i>correct</i> 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.)<p>* 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.<p>* Spaghetti can be avoided (if you so desire) in the same way as the previous point.<p>What you do achieve is that at least you can <i>test</i> that Oom condition. Perhaps what you actually want is an allocator that allows for simulating a particular max heap size.
The article starts with:<p><pre><code> > 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
</code></pre>
Then lists 4x bullet points about why it is bad.<p>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.
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.
Moving all allocations outside the library was also explored in [Minimalist C Libraries](<a href="https://nullprogram.com/blog/2018/06/10/" rel="nofollow">https://nullprogram.com/blog/2018/06/10/</a>)
Interesting conclusion. I recently tried something similar and gave up. The extra lifetimes are awful. Including in author’s post, imho.<p>Rust sucks at arenas. I love Rust. But you have to embrace RAII spaghetti or you’re gonna have an awful, miserable time.
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<p>The only point I agree with is the deallocation in batches being more efficient.<p>> Lack of predictability. It usually is impossible to predict up-front how much resources will the program consume. Instead, resource-consumption is observed empirically.<p>I really don´t understand this point.
C++ problem isn't just RAII, it's the language becomes an unreadable mess, just like this Rust code<p>C++ and Rust share the same criticism<p>- poor readability<p>- poor code navigation<p>- poor compilation speed<p>I find it interesting how they call simplicity "hard mode", quite concerning
> Ray tracing is an embarrassingly parallel task<p>Yet, most implementations do not consider SIMD parallelism, or they do it in a non-robust fashion, trusting the compiler to auto-vectorize.
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.
> 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.<p>I did exactly this in my QR Code generator library, C port and second Rust port: <a href="https://github.com/nayuki/QR-Code-generator/blob/master/c/qrcodegen.h">https://github.com/nayuki/QR-Code-generator/blob/master/c/qr...</a> , <a href="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...</a><p>Writing the Rust code felt way safer because the language took care of enforcing rules about borrowing parts of the buffer.
I think Haskell also pushes you in this direction. It gets super annoying to annotate every function with ‘IO’ and really difficult to test.<p>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.<p>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.<p><i>Update</i>: missing word
> It’s on the caller to explicitly implement a concurrent queue to distributed specific work items<p>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...
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.<p>Maybe I should practice it a bit more.
> 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?<p>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).
I usually like matklad's writings but I have to be overly dismissive for a change.<p>This is a skill issue.<p>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 <i>must</i> 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.<p>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.<p>This is a bread and butter architecture concern for systems programming and if you're <i>not</i> doing it, get good at it.