Rust is not a product, it is a feature. Soon better languages will adopt the borrowing mechanism and Rust will be just one of many.
Discussion
define "better languages" :)
Yes, and also features (like borrowing in rust) are very small part of what makes the experience of using some programming language. Over the years I realized that aspects like overall ecosystem are much more important. Where can you go for help with strange issues and how likely is it that you will find the answers quickly? What libraries are available and who is supporting them? Who is developing the language/compiler/tooling and in what direction are they taking it? What are their priorities? What tooling is available? How does debugging experience looks like? These are in my opinion much more important than some feature or syntax sugar.
What about languages that has autofree memory without borrow shit?
"I am not here to tell you Rust is the best programming language. You should have figured by now." ~ Jester Hartman
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.
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.
Please ser wot mean “borrowing mechanism” I but humble R programmer, wot mean
Programs must allocate memory and free memory after they stop using them. Some languages (C) require you to do that stuff manually, others (Go) have a running routine that inspects your memory at runtime in order to identify pieces of memory that aren't being used anymore and cleans those automatically. Rust has invented a mechanism that allows you to write code in such a way that the compiler knows, at compile-time, when every bit of memory is not being used anymore, so it can automatically free those without having to run a process that inspects everything all the time, which can be slow.