Hacker News Reader

Comment by gituliar | Hacker News Reader

> Unfortunately, I am all too well aware of why these decisions were made, and it is exactly one reason: Compatibility with legacy code. C++ has no editions system, no way to deprecate core language features.

Actually, I'm curious if somebody is working on a flavor of the modern C++ that abandons backward compatibility ?

The Carbon project feels like a completely new language. What I'd expect instead is something that adopts best features and practices from modern C++, so that an average C++ project would require just minor changes to migrate, in spirit of Python 2 -> 3 migration.

View on HN

Have you looked at the CppFront[1] project by Herb Sutter? It's less of a completely new language like Carbon. It's meant to be C++ with a "nicer" syntax, while providing 100% linking compatibility, and with 100% source backward compatibility available when desired.

[1] https://github.com/hsutter/cppfront

> I'm curious if somebody is working on a flavor of the modern C++ that abandons backward compatibility ?

This is just Rust. You can't really deprecate bare pointers in C++ without completely wrecking the language.

This... seems false? In particular, the point of an "edition" system is that code written for the new edition can seamlessly import code written for the old edition, and so a hypothetical pointerless "new edition" would simply disallow bare pointers in new files, and things like smart pointers would continue to be _implemented_ in old edition code.

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631

(I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

> would simply disallow bare pointers in new files

And all their header files. That's a real Year Zero moment: you've just cut yourself off from the standard library, as well as most of the code you might want to link to. I don't think there's any "simpler" about it.

You can get to a pretty clean modern C++ by convention and compiler warnings and static analysis.

Carbon is a completely new language, and that's the point. Part of the language design is making compilation a lot faster, for example, as well as features that C++ can't realistically implement, while retaining C++ interop. It's an exciting way forward if they manage to achieve their goals, and it would be a way to gradually migrate C++ projects.

A new language will eventually acquire its own grungy legacy just like C++ did, unless that new language aggressively breaks backward compatibility.

I think the best practice is for people to stick to a subset of safe patterns in mature languages. For C++, that's probably the C++ Core Guidelines:

https://isocpp.github.io/CppCoreGuidelines/

C++ was grungy in the 90’s, and, well, Rust as it is now is better than C++ as it is now, the comparison that matters now. Rust in 30 years will be better than C++ in 30 years. And safety is a big deal feature, and Rust has it. If it doesn’t have future big deal features, future languages can have it.

I reject the notion that C++‘s “maturity” is a substantial advantage given its unsafety.

Reply on news.ycombinator.com