Stop making me memorize the borrow checker

I don't really agree with this. I'd phrase it more as, you have to learn to really understand what the borrow checker is trying to do and how it makes you architect your programs and consider that ahead of time. Once you understand that, you'll rarely have problems with the borrow checker. It does preclude significant chunks of styles and data structures often used in other languages though.

> it makes you architect your programs and consider that ahead of time

This only works for projects which do not involve any R&D, but have a complete and well written functional specification written in advance. Also for projects which do a complete re-implementation of some pre-existing software.

For greenfield projects which require substantial amount of R&D, it’s impossible to architect programs ahead of time. At the start of the development, people only have a wishlist. Architecture comes later, after several prototypes implemented and evaluated, and people have some general understanding what does and doesn’t work, and what specifically needs to be done.

Rust implies that upfront architecture costs even for prototypes.

Agreed. This is probably the reason why rewriting in Rust "works" -- because the architecture has been previously worked out.

I don't really agree with that interpretation. In my opinion and experience, it does not restrict architectural choices to the extent that it makes it difficult to develop greenfield projects. It's more that it rules out a relatively small subset of architectural choices which are arguably a bad idea anyways, as they do infact have flaws that may not be obvious at first but will lead to a lot of pain if the project grows above a certain size.

> rules out a relatively small subset of architectural choices which are arguably a bad idea anyways

Just because an algorithm is not representable in safe rust doesn’t mean it’s a bad idea. See my other comment in this topic https://news.ycombinator.com/item?id=42164582 You’ll find similar parallel algorithms in all high-performance BLAS libraries. On my day job I sometimes do similar things in C++, using OpenMP or other thread pool for parallelism.

That I can agree with. I think Rust strikes a pretty good balance with it though. You can still do those things if you really need to, but it has to be marked `unsafe`. This bounds the unsafety to only the parts of the code that actually need it, allowing those parts to be examined more closely to ensure they actually are correct.

> I think Rust strikes a pretty good balance with it though

I don’t like that balance.

For performance-critical things like BLAS and other low-level numerical stuff, C++ is safer than unsafe Rust because standard library and tooling (debug heap, debug allocators, ASAN, etc.) evolved for decades making the language usable despite the unsafety. Another thing, for numerical code you probably need SIMD intrinsics. They were defined by Intel, documentation and other learning resources almost exclusively target C language; C++ got them for free due to compatibility.

For high-level pieces which are not that performance critical, I use C#. Due to VM, it’s safer than Rust. Due to GC and other design choices usability is way better than Rust, e.g. in C# asynchronous I/O is almost trivial with async/await. The runtime is cross-platform, I have shipped production-quality embedded ARM Linux applications built mostly with C#. Unlike Java, it’s easy to consume unmanaged C++ DLLs using C API, or even C++ API: see that library to do that on Linux which doesn’t have COM interop in the runtime https://github.com/Const-me/ComLightInterop