Hacker News Reader

Comment by tcbawo | Hacker News Reader

IMHO, Herb Sutter was spot on in his talk (https://youtu.be/fJvPBHErF2U) that it is impossible to walk back features of a language once they are in the wild. His cppfront is an interesting and refreshing approach. I think his “create a TypeScript for C++”, ie. generate safe, easy to understand, conforming C++ is the optimal path for where we are. Dealing with legacy codebases to evolve the language into something else is monumentally more difficult. And I tend to argue that maintaining legacy C++ systems with decades of features and bug fixes is okay for the right applications today.

View on HN

That's Hyrum's law, basically.

With feature flags and epochs, it is possible to evolve C++ in the right direction with the minimum of friction and make it opt-in in a consistent fashion. Circle already proves this a feasible approach, and that's a one-man project. There's also clang tooling that modernizes old C++, and huge amounts of work on LSPs and the like for refactoring, so it is possible to provide tooling that mechanically fixes-up a large portion of old code.

As much as I appreciate the intentions of those working on the successor languages, they have invariably already sunk the ship before even setting sail in my opinion. They are already too fragmented, Carbon, Cppfront, Circle and probably more. By fragmenting they destroyed the only viable future I saw for them. If you want the goals of those languages, there is Rust today that gives you that and more. I'm not alone with that opinion, I know several people in the C++ standard committee that think this way. Even fluent interop is a race they are loosing.

My leading comment - "How do I get to Dublin?" "Well I wouldn't start here"

All of the alternatives you (and I) mention - Carbon, Cppfront, Circle, aren't really fragmentation. They're all experiments at the moment, and all useful in testing out ideas in various different independent directions.

The only comment I'll make about Rust, is that it's going to do a C++, and inspire another generation of languages (e.g. Hylo) that will takes lessons from it and improve - perhaps a nicer syntax, or better type inference and generics, or more formal proofs baked into the language. It's not an end-point.

Can C++ be truly safe? I don't know, to me it seems totally at odds with where the language started, choices made and baked into the language, and where the very broad community and committee currently are.

I agree, Rust will certainly not be the end all language. The original language creator Graydon Hoare has interesting insights into what's next https://graydon2.dreamwidth.org/253769.html.

Regarding successor languages, I fail to see how they are innovating though. Their sales pitch as far as I know, boils down to "Look Ma we have Rust at home". Which I don't find very compelling.

How did Carbon, Cppfront, and Circle sink the effort for safer C++?

Did TypeScript, Flow, Closure, Elm, ReScript sink the effort for safer JS?

While your examples might sound like a similar situation, I'd argue they differ in significant ways. Web was and is the largest software delivery platform. From that perspective it's more akin to x86 machine code. For a long time it was the format you needed to output to partake in that ecosystem without alternatives. A more fitting comparison in my eyes is Kotlin for Java. And if there would have been a single project the community backed, I could have seen a similar situation arising. But as it stands, I don't see that happening.

Kotlin, Scala, Groovy, Clojure

(None of these looking to make Java safer per se, but rather more usable/less verbose.)

With cppfront, Sutter is explicitly not trying to create a successor language. His goal (like TypeScript to JavaScript) is to provide a complimentary, parallel language which provides complete forwards/backwards compatibility with C++. His hope is that (like TypeScript), the languages and communities evolve together. Any other technology that involves developing new tools, migrating code, or lacks completely frictionless interop will be inherently fragmentary. It reminds me of the classic XKCD comic: https://xkcd.com/927/

That is like saying C++ and Objective-C aren't successor languages to C, because their original implementations compiled to C.

That's a nice goal, and if the large majority of the community would back this one attempt it might work. But the presence of Carbon and Circle make that a pipe dream IMO.

Reply on news.ycombinator.com