This post will trouble many Rust fans, tempting them to "downvote it to oblivion", because it voices uncomfortable truths.
This is a critical time in Rust's history, and choices made now will determine whether Rust succeeds and achieves a long-lasting and influential presence, or fades into fond obscurity like the overwhelming majority of its kin. Make no mistake, the latter course remains very, very possible. At their peaks, no one would have believed this fate would take Common Lisp, Ada, Oberon or Pascal. Each had a vigorous ecosystem and numerous devoted users and implementers. Each still has devotees in its obscurity, but each's present obscurity is undeniable.
These truths must be voiced, and acted on, if Rust is not to share the fate of those once equally-vigorous languages.
The first uncomfortable truth is that the numbers matter. It is not enough, for a language to succeed, to gain new users, trying out the language, at a satisfying rate. They must also remain users, and must find, before they give up, that early difficulties adjusting fade. They must find the language better, on all the axes that really matter, for the problems they face, than what they have used before. Hard as it may be for it fans to believe, this is not the universal experience. Rust is stronger on some axes than the languages people come to it from, and weaker on others. It must become strong on all.
The borrow checker, as it is implemented, ultimately turns away too many new users before they achieve proficiency, and burdens exploratory designs when they are least ready to carry it. The slowness of builds is an enduring impediment to production use that will not continue to be excused. The NPM-like ease of falling into unwise dependency on abandoned library components, and the permanence of unfairly-claimed names in the repository, are traps that lead to troubling experiences. Scrupulous users will identify other problems.
To achieve maturity is not the norm, for any language. It is, it must be repeated, a game of numbers. A large-enough number of people must be motivated to try it. A large-enough subset of those must find enough to like to motivate them to continue learning. Enough of them must stay long enough to learn enough to do their regular work in the language. And, enough of those still on board must find a place where they can actually do their work in the language. If any of these numbers is not large enough, for long enough, the language will unavoidably fade into obscurity, deserved or not.
As popular as Rust already is in some pockets of the wide internet, these numbers are not now large enough for Rust to endure and not fade. The window during which its newness and trendiness are enough, on their own, to motivate people to try it is rapidly closing.
While nothing can guarantee success, many things can guarantee failure. One of the latter would be not to change what keeps the numbers down. Needed changes will be unpopular with self-selected early adopters who overcame difficulties and have little contact with those who did not, and left; but change is necessary.
The first and most uncomfortable change needed is to make the borrow checker less draconian. Allow beginners to know how many violations they have, yet run. A running and useful program motivates improvement at every level, ultimately including rigor. Dead code benefits no one, howsoever clean it is.
Beginners exploring the language need early, even if partial, successes. Everyone exploring the design of a new program has far more urgent concerns than borrow rigor. Those can always be returned to, in time, and will be if they remain visible. Allow libraries with violations to be used, and even to be shared, unguarded by "unsafe" blocks; still noting, in each build, how many violations remain.
Rust's reason for being invented was to displace unsafe languages from use where they are most harmful, most particularly C. In this it is, however resolutely, failing. The C users who remain have seen many, many languages rise to popularity and fade away, and have resisted all temptation. They are self-selected to continue resisting temptation. Most remaining C users love it for its faults. They are proud to overcome C's faults, individually, without help.
Most former C users who might have jumped already did. Many jumped to C++. Coding C++98 is enough like coding C that the merits of Rust, particularly its modernity and its initial simplicity, had appeal. But Rust has become complicated, and C++ has evolved, through C++11, C++14, C++17, now C++20, soon 23, and 26. Coding C++20 is little like coding C++98; 98's temptations to unsafety do not appeal.
Furthermore, C++ is and will remain a much stronger language than Rust for capturing semantics in libraries. Moving to Rust means a dizzying step down in expressive power, both in ability to capture semantics in libraries and to use the uniquely powerful libraries it has enabled. While such power is needed in a minority of applications, it is needed badly there. C++ is not being displaced by Rust.
New Rust users are coming, predominantly, from other languages instead, notably Java and Go, and scripting languages. Rust is an overwhelmingly better design than the first two, and runs overwhelmingly faster than the others. But its safety, when borrow-clean, does not distinguish it from them. The appeal of safety is not what wins the users it gains today.
Rust wins users from these languages by being a better experience. The borrow checker is just tolerated, in exchange for the language's modern and substantially more powerful design, including its Drop trait that enables programmed control of resources, its default const and default pass-by-move semantics, and the careful, comprehensive and coherent design of its built-in and core library types.
If Rust succeeds and does not fade, it will be by playing to these strengths among current users of these other languages, but moreso by resolving its weaknesses. The painfully slow compiler can and must be replaced, if it cannot be fixed. The library ecosystem must be made a strength, not a cause of weakness and fragile dependency. And the borrow checker must become an aid to rigor, not a gauntlet for beginners to suffer and, too often, fall to.
Rust's future will be assured only when more complain of its flaws than boast of its successes.
Thanks for all the thought you put into this post.
While I think some of your points have value, I'm not sure this is best time/place to have this discussion. Perhaps /r/rust or a blog post might allow you to have the discussion you are hoping for.
Please, turn this into blogpost. I’ve had very similar feelings for some time.
I tolerate the borrow checker because I want to use Rust’s other features. I think Rust with no borrow checker is much closer to my dream language than it is right now. Rust with an optional borrow checker is in fact even better.
What would Rust without a borrow checker look like to you? Syntactic sugar or automatic wrapping of types in Box and Arc as appropriate? auto-cloning of !Copy types?
I’d start from allowing multiple mutable references. Second would probably be something about relaxing lifetimes but I can’t properly articulate it right now.
Start by allowing anything at all: not ignoring it, but reporting it. And continue reporting it, until it is wrapped in "unsafe" or fixed.
It would not be a mistake to report the total number of "unsafe" blocks harbored in the program when it is linked, from all sources, alongside the live borrow violations. Safety, like development, is a process, not an endpoint.
> New Rust users are coming, predominantly, from other languages instead, notably Java and Go, and scripting languages
True
> The appeal of safety is not what wins the users it gains today.
You are wrong here, mate. If borrow checker prevents mass adoption, I am okay with that. I have dabbled enough problems in poorly written code by "full stack" developers who write code by combining different blog-posts from Medium without any thoughts to underlying memory model, that I am happy that some language feature prevents these folks to take up a Language.
This is a critical time in Rust's history, and choices made now will determine whether Rust succeeds and achieves a long-lasting and influential presence, or fades into fond obscurity like the overwhelming majority of its kin. Make no mistake, the latter course remains very, very possible. At their peaks, no one would have believed this fate would take Common Lisp, Ada, Oberon or Pascal. Each had a vigorous ecosystem and numerous devoted users and implementers. Each still has devotees in its obscurity, but each's present obscurity is undeniable.
These truths must be voiced, and acted on, if Rust is not to share the fate of those once equally-vigorous languages.
The first uncomfortable truth is that the numbers matter. It is not enough, for a language to succeed, to gain new users, trying out the language, at a satisfying rate. They must also remain users, and must find, before they give up, that early difficulties adjusting fade. They must find the language better, on all the axes that really matter, for the problems they face, than what they have used before. Hard as it may be for it fans to believe, this is not the universal experience. Rust is stronger on some axes than the languages people come to it from, and weaker on others. It must become strong on all.
The borrow checker, as it is implemented, ultimately turns away too many new users before they achieve proficiency, and burdens exploratory designs when they are least ready to carry it. The slowness of builds is an enduring impediment to production use that will not continue to be excused. The NPM-like ease of falling into unwise dependency on abandoned library components, and the permanence of unfairly-claimed names in the repository, are traps that lead to troubling experiences. Scrupulous users will identify other problems.
To achieve maturity is not the norm, for any language. It is, it must be repeated, a game of numbers. A large-enough number of people must be motivated to try it. A large-enough subset of those must find enough to like to motivate them to continue learning. Enough of them must stay long enough to learn enough to do their regular work in the language. And, enough of those still on board must find a place where they can actually do their work in the language. If any of these numbers is not large enough, for long enough, the language will unavoidably fade into obscurity, deserved or not.
As popular as Rust already is in some pockets of the wide internet, these numbers are not now large enough for Rust to endure and not fade. The window during which its newness and trendiness are enough, on their own, to motivate people to try it is rapidly closing.
While nothing can guarantee success, many things can guarantee failure. One of the latter would be not to change what keeps the numbers down. Needed changes will be unpopular with self-selected early adopters who overcame difficulties and have little contact with those who did not, and left; but change is necessary.
The first and most uncomfortable change needed is to make the borrow checker less draconian. Allow beginners to know how many violations they have, yet run. A running and useful program motivates improvement at every level, ultimately including rigor. Dead code benefits no one, howsoever clean it is.
Beginners exploring the language need early, even if partial, successes. Everyone exploring the design of a new program has far more urgent concerns than borrow rigor. Those can always be returned to, in time, and will be if they remain visible. Allow libraries with violations to be used, and even to be shared, unguarded by "unsafe" blocks; still noting, in each build, how many violations remain.
Rust's reason for being invented was to displace unsafe languages from use where they are most harmful, most particularly C. In this it is, however resolutely, failing. The C users who remain have seen many, many languages rise to popularity and fade away, and have resisted all temptation. They are self-selected to continue resisting temptation. Most remaining C users love it for its faults. They are proud to overcome C's faults, individually, without help.
Most former C users who might have jumped already did. Many jumped to C++. Coding C++98 is enough like coding C that the merits of Rust, particularly its modernity and its initial simplicity, had appeal. But Rust has become complicated, and C++ has evolved, through C++11, C++14, C++17, now C++20, soon 23, and 26. Coding C++20 is little like coding C++98; 98's temptations to unsafety do not appeal.
Furthermore, C++ is and will remain a much stronger language than Rust for capturing semantics in libraries. Moving to Rust means a dizzying step down in expressive power, both in ability to capture semantics in libraries and to use the uniquely powerful libraries it has enabled. While such power is needed in a minority of applications, it is needed badly there. C++ is not being displaced by Rust.
New Rust users are coming, predominantly, from other languages instead, notably Java and Go, and scripting languages. Rust is an overwhelmingly better design than the first two, and runs overwhelmingly faster than the others. But its safety, when borrow-clean, does not distinguish it from them. The appeal of safety is not what wins the users it gains today.
Rust wins users from these languages by being a better experience. The borrow checker is just tolerated, in exchange for the language's modern and substantially more powerful design, including its Drop trait that enables programmed control of resources, its default const and default pass-by-move semantics, and the careful, comprehensive and coherent design of its built-in and core library types.
If Rust succeeds and does not fade, it will be by playing to these strengths among current users of these other languages, but moreso by resolving its weaknesses. The painfully slow compiler can and must be replaced, if it cannot be fixed. The library ecosystem must be made a strength, not a cause of weakness and fragile dependency. And the borrow checker must become an aid to rigor, not a gauntlet for beginners to suffer and, too often, fall to.
Rust's future will be assured only when more complain of its flaws than boast of its successes.