Laying the foundation for Rust’s future

Oh, I honestly never expected that line. Good job, and good luck to the foundation efforts.

Good idea. I can definately see this working out for Rust.

> The various trademarks and domain names associated with Rust, Cargo, and crates.io will move into the foundation, which will also take financial responsibility for the costs they incur.

Very important folks.

This direction looks very interesting. We'll see what happens.

If other shelved or high risk Mozilla projects such as MDN , servo , thunderbird setup similarly it would enable us to directly contribute to the projects instead of the foundation or not at all.

The only project the corporation would never let go is Firefox as it their revenue source , however other projects could perhaps be salvaged

Will is be US-based like Mozilla, or will it be somewhere else, like Europe?

A couple of foundations have moved away from the US in recent years, for example the Eclipse Foundation (Belgium) and the RISC-V Foundation (Switzerland).

It seems foundational (if you'd forgive the pun) to know under what laws the foundation will operate, and who (if anybody) will be excluded from taking part in the project because of sanctions regimes.

The big distinction between the two of them is that donations to a 501(c)(3) charity are tax deductible and therefore may not be used to unduly advantage any commercial entity, while donations to a 501(c)(6) are not tax deductible and thus are unrestricted.

If it's a 501(c)(6), then the foundation will serve its biggest donors first and foremost. In theory, it may also serve the public good — but only to the extent that it is in the interest of those donors.

Best of luck to the Rust foundation.

> If anything, I’d love to know how many Mozilla employees were working on Rust full-time as their paid job before the layoffs, and then after. I can’t find these numbers cited anywhere.

My idea of programming languages is that they are better when they are designed with their use case. And in the case of Rust, it is to make a web browser engine. I don't know what the current situation is with Servo but I think that it would be a good thing to keep a privileged relationship between the Servo team (or what is left of it) and the Rust foundation.

Rust is not for every project, in fact it is terrible for many projects, but if your project has the same needs as for a web browser engine, then it is great. By making the foundation too independent, we may end up with a monster (no need for another C++), a useless "jack of all trades, master of none", or simply lacking features that are essential for making a good web browser because it is not good enough for some committee.

  's/Mozilla Foundation/Rust Foundation/g'

IMHO, this was overdue: Rust's impact and influence today is global, and extends well beyond the confines of Mozilla. Many businesses and organizations building mission-critical applications with Rust will now be able to support and influence development of the language more directly through the new foundation. Long term, I have an inkling that it will lead to greater/broader adoption of Rust.

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.

I'm playing with various PLs designed for safe concurrency, including this one called Pony:

https://news.ycombinator.com/item?id=24201754

Hopefully not off topic, as both Rust and Pony share a similar agenda.

I mean, if there's any time where you want to be clear about the distinction it would be now, right? What people who really care about Rust need to know now is that it will prosper outside the control of its corporate backer.

Telling us the Mozilla still supports Rust (at a time where it's by definition true that it is reducing its support) is communication that should come from Mozilla, not rust-lang.org.