The biggest threat to Rust's sustainability

Regular releases of the compiler are awesome for the same reason continuous deployment of web apps is - each release only packs a small number of features. The chances of something breaking are much smaller than if it was a massive release of hundreds of features, all of which need to be tested in isolation and then with each other. The releases page (https://github.com/rust-lang/rust/blob/master/RELEASES.md) shows how rare it is for a fix release to be made. Even when it is, it's something minor.

Making the language easier to learn is a high priority. Many people are working on this actively right now - better documentation, better error messages, better IDE experience and so on. OP has misdiagnosed the root cause and blamed something that actually makes it easier to learn the language.

Perhaps I'm being too conservative but I'd have more trust in the language if things were moving slower especially that rust positions itself as a systems programming language fit for production (today). Which is odd because what I want from something that ticks these 2 boxes is interface stability. I have more confidence in Zig or Nim for this reason. Give it another 5 years and it will be a similar mess as C++, or worse: Python (which ended up rolling out v3 which wasn't backward compatible with v2). Also the "safety/security" argument which is their big selling-point which goes out the window as soon as you pull 3rd party crates (as is the case in most of the projects).

This is just a report of the voices of the people I'm converting to Rust because they are never heard.

The compound effect of small and fast changes is complexity.

Uncontrolled complexity is the thing we want to avoid as it's fatal to any project.

Yes there are editions. But from a newcomer's point of view they only add complexity.

I'm convinced that short release cycle and feature 'bloat' are related. I simply don't want Rust to become the new C++ (which is the feeling of a lot of people).

https://medium.com/pm101/spotify-squad-framework-part-i-8f74...

I also understand that Rust is quite backwards compatible which is good but a planned better version of releases would be easier for everyone to keep track, update codes, etc.

There have been at least two cases where Firefox build broke due to having a too recent version of Rust installed. The stability guarantees may be fairly strong but it's definitely not perfect.

It's the classic elevator issue in reverse. If you want to make an elevator faster, put up mirrors so people look at themselves instead of their watch.

Rust appears to change fast, because the changelogs are so detailed, but actually it's stable. Maybe we need to hide the detailed changelog and replace the main one with "minor bugfixes and constness updates".

While perhaps not a large change in practice, this seems like the sort of thing that incurs a large cost when it comes to updating your mental model of how the compiler works, what it can and cannot do, and what options you have when it comes to implementing something.

Contrast this to e.g. Go, which has a ~6 month update cycle, and most of the updates are boring. The main thing relevant to me personally for Go's recent 1.16 update is embedding files, and that's more of a "I can use it when I get to it" thing. Rarely does a Go update require action on my part, and since I started using it full time January last year, I've NEVER had to change any existing code. Neither required, nor because the language has solved something more clever.

Granted, that could be considered a bad thing, and I wouldn't mind some additional features to reduce the amount of code I have to write and maintain, but still.

I appreciate Rust is more complex than other languages and much less easier to pick up and learn on the job though. It definitely takes a lot of practice to get to the point where traits/lifetimes/ownership etc feel like brilliant tools rather than needless complexity.

Comparing a language with a fairly significant runtime and garbage collection to a language with basically no runtime and strict (albeit largely automated) compile-time memory management is comparing chalk and cheese. You might as well say "I tried C++ but ended up going with Python because it was quicker to code" -- of course it was!

In c++ there are foot-guns on every turn. Follow the links for some goodies:

https://en.cppreference.com/w/cpp/language/value_category

https://en.cppreference.com/w/cpp/language/reference_initial...

https://en.cppreference.com/w/cpp/language/template_speciali...

https://en.cppreference.com/w/cpp/language/overload_resoluti...

Building cli tools in crystal is fairly easy thank to the standard OptionParser library. `colorize` is almost perfect, too, in case you want to print some ascii colors. And just like ruby, invoking some shell command is simply wrapping the command with backticks. and FileUtils has ton of features.

Too bad Crystal now only works in POSIX.

That is something that is missing in the article. I think it is valuable to know about these opinions, so thanks for sharing them.

Both here and /r/rust (https://old.reddit.com/r/rust/comments/m7seki/the_biggest_th...), this has been pretty thoroughly debunked. If you still hold your position after reading all the comments, I’d be interested in a rebuttal.

As I said over in /r/rust, I think this claim of yours is still interesting because it’s a matter of perceptions. I’m certain that this perception is erroneous, but impressions still matter. If you want to succeed, it helps to manage public relations proactively.

This is no indictment. Rather, it is a necessity, and a prerequisite to industrial success. The world is complex, and will not adapt itself to a language. A language must adapt itself to the problems the world needs solved. Failing to address a need sends users to languages that do not.

The best that can be done is to start as simple as possible, and then develop as required. (C++ did did not get the luxury of starting simple, but only as simple as was, then and there, possible.) Every language that succeeds becomes, eventually, as complex as its users can handle. The limit is human-scale. The pressure to grow has no natural limit.

There is a real sense in which added complication is needed to give an experience of better simplicity. We see this frequently in releases: restriction X has been removed. The surface texture of the language has become smoother, at the expense of the implemention, which needs to grow to implement the relaxed restriction.

It is always easy to justify removing restrictions, simplifying the description of the language. But this is how languages grow. As restrictions are removed, code in the language becomes simpler. The language takes on more responsibility, so the programmer has less. This is a positive development.

Rust is already a language that caters mainly to professionals, that demands serious education to adopt successfully. The majority of programmers will never succeed in adopting Rust. That was an early choice.

Every language is determined by its choices, which box in unpredictable later choices. Sometimes the right early choice forces what seems like a wrong later choice. That is our lot as humans in an unfolding world.

Celebrate Rust's trajectory as exactly what is needed to mature and succeed in a difficult world.

As for LTS, there is indeed a stand-off with Linux distros. Rust bets on Chrome's update model, where updates are small and backwards-compatible, so everyone is on the latest, and versions don't matter. Linux distros want Rust to have Internet Explorer update model where there are only updates every X months or years, and developers have to specifically test and work around to support multiple old versions.

Note that Editions aren't language versions. They're like "use strict" in JS. They only toggle warnings and small parsing details, but there's only one Rust version. Every Rust edition can use any Rust feature, as long as it parses. For example, everything new added in 2020 is available in the Rust 2015 edition.

You can argue that Rust could do better, but using the military as an example of doing it "right" is kinda funny.

1) The military changes specifications all the time, which is a big reason why so many projects go over budget by 300%. Look at the B-1, B-2, F-22, F-35, Space Shuttle, etc. All boondoggles caused by making tons of last minute changes that blow up the entire project.

2) The military is moving away from Ada. The F-35 avionics code was all written in C++. Apparently they decided it was easier to hire existing C++ developers than to teach people Ada.

I definitely don't get the feeling that C++ was that popular, I distintcly remember many Linus rants about it. It's just that after years of usage it carved its own niche.

However one pain point Rust does address is parallelism. If you want to use modern systems, and you're going with C++. Good luck. You're gonna need it.

As for the popularity, I think that's moot. But I do agree Rust can't be everything to everyone. One problem it will have for the forseable future, is the slow compile speed. But on the flip side, Rust has been super popular.

But it does one thing no other language does. Safe concurrency without GC. It's like a seatbelt in a car. Once you get used to it, you'll be paranoid its not there.

----

Where I do agree with article author was rate of change. IMO Pin should have never been added to standard library as it currently is. But async was rushed, for god knows what reasons.

I guess the dream of a perfect low+high level language will never die.

You seem to imply that it's fundamentally impossible ?

... and... doesn't it still work ? An awful lot of C++ applications are being written today, and that can be done at a pretty high abstraction level thanks to the type-level facilities of C++.

> . Few in the embedded space find it appealing, many of those who use C++ do (as it is certainly a cleaned-up C++, and a nice improvement in comparison), but too often not appealing enough to switch now, and some in the application space who don't know or don't remember the C++ lesson do adopt it now (sometimes out of sheer novelty) but will likely abandon it later for similar reasons C++ was largely abandoned in that space.

are we talking about the same embedded? most C shop migrate to C++. most car brands, and a lot of appliances, use Qt for their UI (C++)

Whereas Rust, to me at least, is 'ML-ish with curly braces'. So, a language firmly based in the ML heritage with C-like syntax. So, fundamentally working with types and 'typeclasses' and heavily leaning towards filter/map/fold/reduce/lift/unlift type of thinking. Sure, throwing funtions around as first class objects are not as easy or straightforward as it is in 'real FP' languages, but that's a trade-off I'm willing to take for the guarantees that Rust provides.

I'm genuinely curious what's the reasoning behind being able to assert that 'Rust is a cleaned-up C++'.

"It's simpler than C++!". Yeah, Rust could become a bloated mess and still be simpler than C++. It's like saying that a mountain is not high because it's smaller than the Everest. It's not a good idea to use C++ as reference.

I wish there was a C with a borrow-checker like Rust, but without everything else.

And what decisions would that be? Your post seems self contradictory to me because it implies that Rust is both too "low abstraction" to be "extremely appealing" to C++ crowd, and too complex and "hard to analyze" to displace C in use-cases that require portability and/or are resource constrained.

Not really; Rust is very careful to avoid leaky abstractions, compared to C++. It's definitely "low level" in a foundational sense (even reminiscent of C in many ways) but the limited "high-level" features it does have are incredibly solid and highly usable.

Additionally at least on Windows, Microsoft still believes in C++ for doing the kind of desktop applications you are talking about.

All these scenarios aren't properly covered by Rust in its current state, even the Rust/WinRT project is doing baby steps, very far away from what VC++ offers today.

Haskell doesn't promise the type of control I need. Someone i work with rewrote our main control algorithm and proved it was correct (not in Haskell ,I just fear this problem ), but it took over a minute to run, and this PID loop needs to run at 5hz and leave some processor for other tasks. My c++ isn't proven correct but we have 15 years of production with it.

Rust promises to avoid some of the things we don't like about c++ while still worming in the real world. So of course I'm interested.

Apart from that, Perl is not a substitute for Rust or vice versa, regardless of the amount of typing involved.

It... doesn't, though? Rust's syntax is pretty aggressively conventional, from my perspective.

Looking at the punctuation symbol tokens, almost all of this is common to many languages: https://doc.rust-lang.org/reference/tokens.html#punctuation

The symbols that come to mind when I think about my experiences writing Rust are: - <> for generics - ? for early-return errors - Macro invocations require a ! - Match statements use => - ' for lifetimes - #[attrname] for attributes - |x,y| for closures - -> for return types

All the other common symbols I use feel too conventional to seem worth mentioning, like {} for lexical scopes, = for assignment, +-/ for math, foo() for function calls, foo.bar() for method calls, (a,b,c) for tuples, [1,2,3,4] for arrays, <>!== for comparison, "quoted" 'strings', / comments */ and //comments, etc.

I agree that might_fail()? and 'lifetime are different, but everything else I listed seems lightweight, and very common for languages to use symbols for. <> is common for generics from C++, but alternatives I've seen are [] and (), also symbols. Matches use =>, and C's switch cases use :, also a symbol.

Using macro_rules to define macros is pretty symbol-heavy, I guess?

Usually when I see complaints like this, they come down to complaints about the lifetime syntax, and not liking the use of ' for anything besides quoted strings.

If you disagree, could you explain how I've missed or misunderstood your point? Can you show some examples of normal Rust code that uses way more symbols than normal Perl?

While in fact Rust 1.0 was a bare-bones MVP, missing basic functionality, with an annoyingly inflexible implementation of the borrow checker. You couldn't print or copy an array larger than 32 elements! People still complain that the standard library can't generate random numbers and you need a 3rd party library to cast an integer to an enum (really!)

Since 1.0, Rust has been mostly filling in holes, and removing gotchas. Apart from async, a lot of changes can be summed up as "this obvious code didn't compile before for weird technical reasons, but now it just compiles".

Async started in 2015 with mio library, which was a thin wrapper over Linux epoll. People have recognized that it's tedious to use it, and proposed Futures in 2016, which made it easier. Multiple limitations of Future's APIs were became apparent, so in 2017-2019 there was a lot of work to remove known problems and annoyances. That's the async API: 4 years of real-world experience and simplification of async code. As someone who's used it during that time I can assure you that `async fn` today is easier and clearer than everything Rust had before it.