| |
 | Posted by Gregor Mückl
in reply to Paulo Pinto |  Permalink Reply |
|
Gregor Mückl 
Posted in reply to Paulo Pinto
| On Saturday, 23 November 2024 at 18:44:55 UTC, Paulo Pinto wrote:
> On Saturday, 23 November 2024 at 01:11:46 UTC, Gregor Mückl wrote:
> On Thursday, 21 November 2024 at 18:43:51 UTC, Kagamin wrote:
> > "I was actually interim chairman of the Rust committee at the Motion Picture Academy last summer," he said. "And it's an interesting language and I enjoyed playing with it, but I was like, I just can't imagine having to rewrite all my software in this."
Quote of the day, lol.
I think that there is a quite common sentiment these days that (a) rust solves a few painful problems nicely, but (b) is too impractical to use at scale.
My prediction right now is that rust won't overtake any of the major languages. Here's why:
-
There is a genuine drive to build a successor that interacts much more nicely with existing code in C and C++. Especially C++ seems to be in this weird spot where it is at the same time a major improvement over C to be worth using, but also starting to overstay its welcome in many teams.
-
Nobody is going to rewrite the world just to get more control over memory bugs. Old code that works is perfectly fine and mostly not a liability in that regard (caveats apply).
-
People want good interop with their existing code when introducing a new language. This isn't a big issue with C, but any more advanced C++ library, for example, is hard to bind to other compiled languages. Some features can't be bound at all unless the target language makes special provisions to enable it (see C++ interop in D and Swift, also C++/CLI).
Rust will probably have its lunch eaten the moment a language comes along that
- is as fast as rust or C++,
- has memory guarantees on par with rust (not necessarily a carbon copy of the rust borrow checker),
- and can interop with more modern languages than C with less friction than rust can.
I assume that there are enough dev leads out there that would literally throw money at such a solution with both hands, so it's bound to happen eventually.
[Also, stupid pet peeve: "memory safety" is the wrong name for what rust accomplishes in my head. I associate "safety" with functional safety, which rust doesn't solve at all.]
That language will arrive too late for what is already happening at Google, Microsoft, Apple, Amazon, Cloudflare, Vercel, Facebook, Activision, Capcom,....
I doubt that. First off, even though you list a couple of big names, they cover only a tiny fraction of the software development that is happening in the world. Also, the decisions they make are highly bespoke to their internal needs - ludicrously big teams and their highly monolithic and sprawling codebases. My experience is that their tooling and decision making is so warped by this that it is foolish to apply (almost) any of that to a project with less than ~100 developers.
This still leaves a world full of "brownfield" projects that can't easily accommodate a second language as different as rust for all kinds of reasons. They would gladly take anything that gives them the same level of results with less friction than rust would. There is heap of real money lying on the table here. Developers don't care much about how these better guarantees are achieved in detail under the hood (e.g. borrow checking). They just want guardrails on what they are doing that catch more mistakes that would be costly, but also with the least intrusiveness on what they do.
Rust is on the very extreme end of a spectrum, mostly because of design decisions that do not concern memory management. The proponents are good at selling it. But there are certainly other sweet spots between C and rust that aren't as radical. People are searching for it (see thread starter for examples - there are more) and at least one of these attempts will be successful. If you want to find true successor languages to C or C++, it will appear in that space.
|
