Hacker News Reader

Comment by bsdpufferfish | Hacker News Reader

To overcome something as entrenched as C++ it has to be 10x better. Even rust isn't there. Most of it's community isn't ex C and C++ experts, it's people getting into low-level programming for the first time, either from scripting language or pure functional.

View on HN

Don't we consider a C/C++ replacement "successful" when it was able to capture enough share of prior C/C++ uses, not the entire share? I never thought C or C++ could be completely gone out of sight, even COBOL is technically alive today (on life support). To be clear, I meant that D could have been in the position of Rust today if done right.

Yes, by that criteria C++ was successful over C. And C was successful over fortran. There are small communities that prefer the older stuff, but they were better enough to move the entire industry.

D isn't, and neither is Rust.

> I meant that D could have been in the position of Rust today if done right.

My point was Rust is just a completely different audience. I suppose D could have sold itself as a better JavaScript.

(Sorry for several rewrites.)

I think you're correct for D, but for Rust, we'll see. It's a very slow moving industry. I do C++ work all day (embedded) and while there's no current plans to move to Rust (which means it won't happen within the next 3-5 years), I could see it occurring someday.

We're finally (usually) allowed to use C++17. I had to use C++03 at times circa 2019 - we're finally done with that. It's _really_ slow moving.

> I could see it occurring someday

"Someday" is on the order of decades here. By that time Rust will be a hoary legacy language with a list of warts longer than an ISO standard.

Nonsense, WG21 is committed to ensuring C++ has more warts and sharp edges than any other language on the planet.

I don't agree. Rust very much wants to be a C++ alternative in all (I mean all) respects.

Not really. The lack of fields in traits or a classical inheritance system is pretty strongly missed by some people coming from C++.

> To be clear, I meant that D could have been in the position of Rust today if done right.

Exactly. One language died arguing about a feature (Dlang), two different languages, one without it (Rust), another with it (Golang) proved that it was not as significant.

I wouldn't consider a C++ (or C) replacement PLₓ successful until the people working on big compiler toolchains—many of whom are committed alternative programming language advocates themselves (consider the origins of e.g. Swift and LLVM)—decide that, moving forward, those will be written in PLₓ rather than C++.

(Note that the bar I'm establishing here is not merely to have a self-hosted compiler (see many toy compilers). I'm talking about a hypothetical future milestone where the software world's core infrastructure comprising LLVM/Clang and* GCC is written in the "replacement language", i.e. the compilers for a bunch of other (non-PLₓ) languages—including C and C++—are written in PLₓ as well. The backends, at least.)

* "or"?

While I do hope that future, it is an unreasonably high bar because the main value of LLVM is that you don't have to make everything again to make your own PL implementation. For the same reason contemporary web browsers are unlikely to be fully rewritten in any other language unless they get completely displaced by newer browsers. (At least LLVM has a better chance of being replaced...)

> contemporary web browsers are unlikely to be fully rewritten in any other language

Right.

> it is an unreasonably high bar

It's not an unreasonable standard. We're talking about replacement. If isn't replacing C++ for this use case, then it's not a replacement by definition.

It's unreasonable in the sense that LLVM and a few others may survive even after pretty much everything else got replaced. We need to exempt some outliers with a very high sunk cost.

A corollary of this is that a language probably needs to be able to interop with C++ to have any chance of being able to replace C++, so that the LLVMs and web browsers of the world can migrate incrementally. GCC was able to migrate from C to C++ because of this, and a migration from C++ to some other PL would need to work similarly.

There are a lot of high profile Rust adoption stories where the developers involved are C and C++ experts. E.g. Rust in the Linux kernel, Rust in the Windows kernel, Rust in Firefox, Rust in Android.

I think the Rust in Firefox is probably the strongest in that list. Rust in Linux is just advocates trying to get adoption (not regular kernel contributors electing to use it).

That's not really accurate. Ojeda is a long time kernel contributor and so are many of the folks writing drivers. Maintainers of various subsystems are also particularly interested.

Not everyone is of course, but hardly "just (Rust) advocates" like you suggest.

Reply on news.ycombinator.com