TehPers

Sorry if I’m missing some sarcasm here, but if this is all you have to contribute, then as a professional software developer, I’d much rather work with the author of the article on a daily basis.

Two thoughts come to mind for me:

1. I think people should feel free to use any language however they want for their own needs and projects, but it’s also important to understand what exactly “unsound” and “undefined behavior” mean if you’re going to dabble with them. If it’s a risk you’re willing to take, go for it, but don’t be surprised if things break in ways that make no sense at all. Realistically a compiler won’t delete your root directory if you trigger UB or anything, but subtle bugs can creep in and change behaviors in ways that still run but which make unrelated code break in difficult to debug ways.
2. The borrow checker is one of Rust’s biggest features, so looking for ways around it feels a bit counterproductive. Feature-wise, Rust has a lot of cool constructs around traits and enums and such, but the language and its libraries are built around the assumption that the guarantees the compiler enforces in safe code will always be true. These guarantees extend beyond the borrow checker to things like string representation and thread safety as well. As an alternative, some other languages (like C++, which you mentioned, or maybe even Zig) might be better suited for this approach to “dirty-but-works” development, and especially with C++, there are some excellent tools and libraries available for game development.

Or look at Python and their urllib, urllib2, new urllib, and the requests package on PyPi.

We already sort of saw this in Rust with crossbeam and standard channels, until of course they replaced the standard lib implementation with crossbeam’s implementation.

Still working on an assertions library that I started a few weeks ago. I finally managed to get async assertions working:

expect!(foo(), when_ready, all, not, to_equal(0)).await;

It also captures values passed down the assertion chain and reports them on failure (without requiring all types to implement Debug since it uses autoref specialization).

Hopefully it’ll be ready for a release soon.

My understanding is that should almost only ever be set for WASM. Certain low-memory machines may also want it, but that’s extremely rare.

I’m not sure who’s recommending it, only ever seen it recommended for WASM applications.