Several core problems with Rust

Spending out something better isn’t easy. As an applications developer I want to ask “Why don’t you just use Java/C#?” and I’d go so far to say that the software reuse revolution behind Java was not OO or it’s particular approach to OO but rather the garbage collector.

That is, building applications out of premade parts is a struggle in C or C++ or rust because memory management is part of the API. C devs would be very concerned about having control of memory allocation and would like to have the choice of reusing a buffer from the application in the library or have the library allocate into an arena managed by the application, etc. It’s complicated enough that libraries can’t reasonably support every scenario application developers would like and ultimately tough because to free something the application has to know if the library is done with it or the library has to know if the application is done with it…. However, the garbage collector knows!. In the end there are a lot of libraries you can’t really write for C or if you can write them you have to write them assuming the application allocates or a certain way or you lose the benefit of being in control of allocation that C allegedly gives you.

On the flip side I think C is too high level in some cases, for instance you come to think the gymnastics involved in written embedded C or device drivers are normal but there are quite a few things that are a little bit cleaner in assembly language and I write things for AVR-8 that are rather small but it drives me nuts that C is moving the stack pointer around and following calling conventions that are not at all necessary for these particular programs.

I had friends who worked in the IBM Mainframe world where it is still common for applications to have bits written in assembly because of efficiency or to get finer control than you can get with COBOL. Part of the COBOL puzzle is that you have to be a Macro Assembler programmer to work on that stuff and you can’t just port it to GNU COBOL on Linux without also porting the assembly!

We’re still living in a multi-architecture world so the interesting idea of trying to make it easier to write assembly (imagine a super macro assembler with an integrated theorem prover) is a non-starter. Let x86 founder for a decade and if RISC-V makes no progress that picture could be different in a few years.

The amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword.

The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind.

Unsafe in a language like Go is very rare, mostly because people do not program at such low system level to get the max performance out of it.

Rust code with unsafe: 1.7M Go code with unsafe: 400k

and for comparison, Go has about 2.3x the amount of repo's. So Rust has about a 10x more usage of the unsafe keyword.

> Unfortunately, it’s impossible to make Rust compile fast. The problem is inherent to all similar generics-heavy languages, like Haskell.

I don't think this is correct, strictly speaking. Furthermore, I think this conflates two common causes of slow generic compilation:

- Type-checking them can take a lot of time

- Generics may be implemented in a way that generates a lot of code

Neither of those are required for generics-heavy languages (e.g., OCaml is generally considered to compile fast despite having a "complex" type system), and the presence of one doesn't necessarily require the other - a hypothetical "simple" generics system with heavy use of monomorphization can end up taking a long time to compile, and a "complex" generics system that erases types may take a while to type-check but could compile fast after that.

> Put a non-optional borrow-checker on top of it

From my understanding the borrow checker usually takes up a small fraction of the time needed to compile. There are cases where that's not true, but I think people tend to overestimate its impact on compile times.

> There are ways to implement unsafe programs that still don’t execute remote code or leak secret — they only corrupt user data and act sporadically.

Reliably implementing unsafe programs that don't have RCEs or leak secrets but still corrupt data and "act sporadically" seems like a very peculiar combination of requirements to me, if it's even possible. "Act sporadically" is also quite nebulous, and depending on the precise issue may in fact be an RCE or secret leak in hiding - after all, it's not that uncommon for exploits to start their life as someone noticing a crash.

> It’s probably the strongest point of my whining: Rust is memory safe and unreliable. The price of memory safety was reliability in addition to the developer’s sanity

I think that is actually one of the weakest points. I didn't see any support for a claim that memory safety necessarily requires trading off reliability, let alone that that is what Rust does.

> Step into the shared mutable state — and there a memory corruption is not an exception, it’s a rule. You have to handle the corruptions, you cannot simply crash.

What definition of "memory corruption" is being used here? I didn't think that's the kind of thing that you usually "handle"...

> Which kinda destroys the first uncompromising thing in Rust — performance.

I feel this misunderstands Rust's priorities. (Safe) Rust prioritizes safety over performance, and that has been a well-known tradeoff for basically its entire lifetime. If you want performance at the expense of safety, that is what `unsafe` is for.

> So, to reiterate, the second you step into the shared mutable state you lose every single advantage of Rust. Which is kinda rational considering that the main concept of Rust was to never employ a shared mutable state.

This misses another useful bit of Rust, which is the ability to contain unsafety to clearly-delimited sections of your codebase.

There's more I could say, but life calls...

It's lock contention that slows things down more than anything.

But it's really an 'it depends' situation.

The fastest algorithms will smartly divide up the shared data being operated on in a way that avoids contention. For example, if working on a matrix, then dividing that matrix into tiles that are concurrently processed.

Having run into memory issues in go but not (yet) in rust I would tend to disagree with this. It's really not hard or esoteric to run into it in go.