[OT] Safer C

[Gregor Mückl]

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.