The borrow checker is way too complicated. Give me a well tuned mark and sweep GC any day. Latency of concurrent processing matters a lot more on a system with heavy load and Rust has zero to add to the field regarding this matter.

Rust is just a fad language, just like C++ was a fad language back in 1992. It has precisely one feature distinct from C++, and cargo is basically a carbon copy of Go's build system with macros added, so, sorry, it doesn't count.

Sure, it saves compilation time, most of the time, but it's still at least 100x faster to compile the same app in Go, versus Rust, from scratch.

I doubt the trade-off of security and safety of the borrow checker really stacks up against the speed of C execution and hand-optimisation.

Variants, objects and templates are very expensive features to compile. Programmers abuse these tools all the time, leading to the endless, predictable bloat of lower throughput and higher resource consumption.

Rust does nothing towards teaching programmers to write simple, clean code. It just gives you a very hard to learn way of making an extra few fractions of a percentage of safety for maybe 10% throughput but gives you no reduction in latency and takes about 3 months for average programmers to master this most fundamental feature.

And like all macro-using, preprocessor using languages, it gives so much expressivity that learning how to do anything with the language starts with a long review of the myriad of options, instead of a solution that is precisely the fit and most concise and performant.

Reply to this note

Please Login to reply.

Discussion

The borrow checker is unfortunately complicated. It forces code to be written in certain ways and not in others. C++ is the fad language used for Bitcoin Core. By its own it enforces simpler programs, I think it's more general programming fads that make the code hard to read.

Maybe C++ and Rust are geared toward large-scale systems with many developers of differing experience and knowledge about the systems. Totally overkill for smaller self-contained codebases, or larger with senior devs.

Agree Rust is overly complicated, would love to see a flavour without async and with fast compilation as a top priority.

GC like async is out of the question for me when it comes to systems programming.

Respect your work.

I've seen several times freelist management packages in projects I've worked on or looked at or used. You can turn off GC with Go, but at that point nothing will get deallocated, so everything has to be reused.

As such, it's not as well suited to embedded or kernel development.

There is an embedded version, "tinygo", that uses other memory management strategies in its much smaller runtime.

I really don't see there being that many cases that can't be faster built and easier to maintain with the help of GC though. Kernels, and minimalistic, embedded apps (think arduino).

The guys who invented Go were 30 year+ veterans of C and C++ programming, one of them even was the co-inventor of C, Ken Thompson. IMO, if they said use GC, then a lot of other people don't know what they are talking about.

Go, like Rust, it is practically impossible to have a stack smashing or other memory allocation error vulnerability. One you can pick up and run with, build something useful in your first weekend with it, the other, you will still be scratching your head 3 months down the track trying to remember everything you have to memorise to use Rust's memory allocation system.

GC vs Borrow checker is down to trade-offs. The former is a well proven strategy, probably easier to implement and less verification work for the compiler. For the time Go was released, it's understandable they went with GC.

Agree on the learning curve.

Would be interesting to see a third language, striving for simplicity and fast compilation but with borrow-checking.

Indeed.

Finally, someone that sees past the fucking Rust cult.

nostr:note1han4vjshrnu4hu59a9czk8jqhfk4afgxkq54x08g9hr0ymrljhlqhyk0n0