But somehow, Rust got cool, and now a large fraction of its community wants to use it to write web services. So there's a lot of gravity dragging the ecosystem, and even the standard library and the language, in that direction. Even though it is a poor choice for almost all web services.
One day, the shine will wear off, and it will be easy to see that it's a poor choice for almost all web services, and we will feel some regret over the amount of time and energy that went into building in that direction.
Time will tell. I used to think this way, but don't anymore.
That doesn't mean it's right for the majority of them, but I think it's workable for a very surprising number of them.
For instance, look at what Cloudflare ended up doing to get Go working as they wanted: https://blog.cloudflare.com/go-dont-collect-my-garbage/
Rust will never be a competitor to Python or PHP (but it can enhance them, because making a native extension in Rust in way easier than in C, especially for people with a web back-end background and little C experience), but Go is losing a lot of appeal now that Rust is here ready for prime time.
Most devops don't use Go and I argue that for the ones who do, Rust is a big improvement. Sure Go is being used to make Docker and k8s, but with this reasoning Haskell is also irreplaceable since Pandoc is made with it… Ironically enough, the mere existence of docker negates the main asset of Go in a devops context: statically linked binaries. Without containers, it's a huge selling point, but as soon as you use docker it brings nothing to the table anymore.
> Using Rust won't translate into better performance without effort. Because of its focus on soundness, I would say that you need to put in even more effort.
Saying so reveals that you've probably never tried it. The biggest performance issues I've been facing where memory allocations. With Go, things are “magically” allocated or not depending on the compiler's mood of the day (or the compiler version in practice) and you need to diagnoses these by looking through the escape analysis log, see when the compiler cannot elide the allocation and refactor until it works. With Rust, you just don't allocate memory unless you're using a `Box` or heap-allocated collection (a Vec or a HashMap for instance).
In both case you can have an implementation with a good performance, but with Go you need tedious tuning, while Rust gives you an explicit control of the allocations. That's an enormous productivity difference.
Actually rust is a grate language for programmers of the less capable end of the spectrum.
While it allows clever abstractions it generally discouraged and recommended to write simple code.
The borrow checker might seem like a clever abstraction, but it's just a build in code analytics tool you should use anyway when using C or C++ or well any language, and it generally nudges you to better structured code.
> Then, as now, they were people who hadn't had much contact with the average software developer and with the realities of software mass-production.
Except that more than just a few decisions in the rust design process where strongly influenced by the feedback of average developers, including people which just got started with programming.
Wrt. C++ I can completely agree, it's a completely over engineered language with endless gotchas with silently sneak into you code without you noticing and potentially causing UB if compiled with some compiler in some optimization levels for some target. Making such bugs completely bonkers to track down.
On the other hand in (safe) rust many of the problems user have come from the language helping you to not run into any of this and other bugs.
And all "hidden" complexity rust has is normally designed in a way so that you don't need to know it to use rust or even things related to it as long as you don't want to create some low level primitives which involve unsafe code.
As a bonus I can pull in serde with one line and use it without worrying about shooting myself in the foot.
Personally, being a Rust enthusiast, I think that Rust's benefits don't just unleash when you think about performance, but also when you think about large codebases. Such codebases are usually the scene for refactorings. In a dynamic language like js, these are extremely hard to pull off. In Rust, the compiler won't stop yelling at you until you have cleanly finished the refactor. I love refactoring Rust codebases, even ones I didn't write, while in C++ or other languages it's extremely annoying.
And note that while C++ enthusiasts might have believed that everything should be C++, not everyone followed them. Many people still stayed with C. Many still do even with Rust around. But there is a small group of people for whom Rust is such a great improvement that they take the portability cost and switch to Rust. Linus is heavily anti C++ for example, but he's open to adding Rust to the kernel.
Now it's Rust based on what? Uber backend is almost entirely built in Go. And so are many other services handling billion plus requests a day written in other languages.
Perhaps Rust advocates know something that Uber engineering does not.
And for the record, when Uber got started Go wasn't available either.
Neither Facebook, nor Instagram or Slack are primarily built on C++ or Rust though. And many other products that I can't as confidently remember from the top of my head aren't.
Only later did they introduce Hack and HHVM, which compiles a PHP dialect in a just in time fashion. My point is that once you reach scale, and your computer bill becomes significant enough, you'll really want to use efficient languages.
What's a better general-purpose language for this mythical "average" developer? Java/C#? Rust has the same level of memory safety, and adds data-race safety that these languages do not have out of the box. Go is in the exact same boat, btw - memory safe for sequential code, but concurrent code is tricky since unsafe shared access is ubiquitous in real-world Go code. Haskell, Agda and Idris could provide more safety but are not approachable to the "average" dev.
You (rightly, I think) place Idris (and Agda, although that's more a proof assistant than a PL) beyond the reach of the average developer, and also, apparently, Haskell -- arguably a simpler language than Rust, but never mind -- but not Rust. And that's my point and, I guess, our point of disagreement. If you think that, on that spectrum between, say, Python and Idris, Rust is at a good level for the average application developer to the point where maintaining high-level applications written in Rust would ever be cost effective, then I think you are out of touch with the realities of the software industry and the economic forces that shape it. I thought the exact same thing as you twenty five years ago: C++ was obviously the right language for the average developer -- even more so than, I don't know, Delphi or Visual Basic -- wasn't it?
> What's a better general-purpose language for this mythical "average" developer?
I don't believe any low-level language will be cost-effective for application development for the foreseeable future, if ever, and the average developer is anything but mythical (I mean, embodied as a single person, perhaps, but I'm talking about teams).
> Rust has the same level of memory safety
It doesn't (due to much more prevalent reliance on unsafe as well as FFI), but that's very much beside the point because, as you acknowledge, safety is not what it's about.
From a PL research point of view maybe.
But from a POV of what is simpler to use for a average or new programmer, Haskell is far worse as far as I can tell.
> due to much more prevalent reliance on unsafe as well as FFI
Where? In embedded programming? Or programming from primitives (which I would argue a average programmer never should do, there are existing libraries)?
In some use-cases you always end up with a FFI, but that is also true for other languages.
Besides that usage of unsafe is both strongly discouraged and uncommon.
There are a lot of rust use cases where using unsafe code is never necessary to a point where people simple ban any direct usage of unsafe code in their project.
A lot of things that are hand waved away in C++ (who owns this? How long does this need to be alive? Can I mutate this?) are completely explicit in a Rust interface. And Rust's type system is strong enough to express a lot of rules that no one would want to write down in C++ (because overriding them is just one cast away), allowing us to write hard-to-misuse libraries.
Coding on top of such libraries is a really fun experience. That's why I call Rust an all level language.
Time is a flat circle.
(See for example the "Empowerment, empowerment everywhere" RustConf 2020 keynote.)
If anything Lisp current adoption proves that aiming to tackle both ends of the spectrum in a single language might not be a good idea.
https://en.wikipedia.org/wiki/Rule_of_least_power
Also, Lisp is the most powerful at constructing programs but that means it's the least powerful in the field of making sure your program actually does what you wanted it to - that's what types, borrow checking, proof assistants and so on are for.
(Some people think Lisp is declarative because it's homoiconic but that's not true - you can't find out what a Lisp macro does without executing it.)
is it a good or a bad thing?
Those who go down that path will experience the same disillusionment we did, and end up with applications that end up costing so much more to maintain if only because of the cost of the maintainers they require. Software costs work better when low-level and high-level programming are kept separate. The former is costlier but tends to be both smaller in size and in prevalence, while the latter is the opposite.
Of course, the number of people who make that mistake of mixing high- and low-level programming won't be nearly as high now as it was back then -- many of us have learned our lesson -- but it would still be interesting to watch this unfold again, even at a small scale. And, thirty years from now, some will be telling us why, while using Rust for high-level programming was indeed, a costly mistake, Muju is completely different, and this time a low-level language really and truly is appropriate for application programming.