The Two Factions of C++ (2024)

ssigna11 3 days ago 25 commentsRead Article on herecomesthemoon.net

ES version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

59% Positive

Analyzed from 1107 words in the discussion.

Discussion (25 Comments)Read Original on HackerNews

tonyedgecombe•7 minutes ago

[delayed]

tialaramex•about 1 hour ago

Should have a (2024) annotation so far as I can see (haven't finished reading the article but it seems to be about events which have "just happened" back then)

also at the time this is what HN wrote about it: https://news.ycombinator.com/item?id=42231489

Rochus•3 days ago

Very interesting summary of facts and quotations with conclusions. I would say there are even more camps than the two mentioned. Personally I think C++98 and Qt5 just worked and were good enough for all purposes, and C++ since has become an ever moving target with a lot of incompatibilities between compilers. Chasing for the ever latest version of the language and compilers is very expensive and enervating. I prefer how they solved this e.g. in the Ada community; they take their time for the release a new standard version, and until then, most compiler vendors have already updated their products and there was relevant experience with the new features long before the new standard was passed. In computer science, it seems to be a law of nature to keep "improving" good things until they become unusable and people walk away. In C++ I did so; I have a few C++11 code bases (some back ported from newer versions), but most are C++98/03; I even made a fork of Qt5 (LeanQt) with my own build system (BUSY) which is less work to maintain than continuously chasing new compiler/tool incompatibilities among platforms.

gignico•about 2 hours ago

I understand the issue about the ever-moving target etc., but almost fifteen years later do you really believe C++98 is better than C++11 without move semantics and decent smart pointers? I remember working with Qt5 and C++98 and yes, it was productive, but it was also a mess of intricate object ownership.

I'm critical about some choices made with C++20 and after, like the mess that modules are, and the too-little-too-late ranges library. C++26 is also a joke imho. But on the other hand, working with std::optional and (in C++23) std::expected is so much better than without. The thing is nobody forces you to use every single feature of a new standard, but I would not recommend ignoring very good tools just for the sake of it.

Rochus•about 1 hour ago

For all of my projects it is good enough. C++11 onwards has a few advantages, but I don't need them. Moving ownership between containers to avoid allocations was possible with the standard library even before C++11, and Qt offered "implicit sharing" which has a similar effect without syntax changes and incompatibilities. Even with my C++11 projects (e.g. https://github.com/rochus-keller/eigen/) I had to take care still in 2024 which feature not to use on MSVC because it didn't work or behaved differently. I never have any ownership issues and I implement large compiler projects with different AST and IR layers. All my projects still compile with https://github.com/rochus-keller/leanqt/ on all platforms. I would never trade a tiny language advantage with a whole world of dependability issues. One day I will revive and refactor GCC 4.7 to get a cross-platform C++98 with parts of 11 compiler just written in C, then latest all of my software is buildable "from first principles".

PS: it's funny I wrote my comment three days (and not an hour) ago.

maleldil•11 minutes ago

> Moving ownership between containers to avoid allocations was possible

That's not the biggest upside of move semantics. You can't safely express smart pointers without move semantics. They tried with std::auto_ptr, and it didn't work.

usrnm•about 1 hour ago

> it was also a mess of intricate object ownership

Not much has changed, though, it still is. Just with a lot more bells and whistles around it

logicchains•about 1 hour ago

>C++26 is also a joke imho.

C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.

tonyedgecombe•4 minutes ago

[delayed]

jstimpfle•27 minutes ago

Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.

gignico•about 1 hour ago

Yes, C++26 reflection is nice, but also extremely complex to understand and use well. The rest of C++26 is the usual series of too-little-too-late additions. Meanwhile I’m still waiting for pattern matching to become a thing (a proposal has been discussed for ages)

mgaunard•about 2 hours ago

It's a committee, many people are involved, all with different opinions, but any decision requires consensus.

Why would anyone expect big broad changes? And historically, whenever they did happen anyway through forced compromise, they resulted in failure because they were not consistently implemented.

The only way that works is small compatible and iterative changes.

tialaramex•22 minutes ago

A big problem is that "consensus" for WG21 is actually just "Did the chair of your sub-sub-committee say there was consensus?" and is typically measured by voting. That's not a consensus, it's a majority.

If you've worked on technical problems with an IETF Working Group you'll know what actual consensus looks like. If you've been around a while you might even have seen abuse of process used to dodge rules and seen demonstrated before you why we need consensus anyway. ISO's procedures are probably adequate for its original goals but they're completely inappropriate for designing a programming language. SC22 should never have existed and is entirely the wrong place to do this work.

aw1621107•about 1 hour ago

Previous HN discussion here (https://news.ycombinator.com/item?id=42231489); 2024-11-24, 554 points, 653 comments

pif•42 minutes ago

> it’s at least a bitter awareness of the fact that the industry doesn’t care to refactor existing code

Refactoring work, terrain tested code?!?

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

rhdunn•36 minutes ago

You can incrementally refactor existing code to make it more maintainable and easier to implement the things you are working on.

The issue with Netscape (per that article) was that it was a rewrite, not a refactor. I.e. replacing all the existing code with new code. That's why it took a long time to release a new version: the previous code hadn't changed and the new code wasn't functionally equivalent to the existing code, let alone have any new features.

froh•21 minutes ago

wait. that's about the green field rewrite of Netscape. not about refactoring where needed.

actually it is very explicitly pushing to refactor and rejuvenate the working field tested code, instead of green field rewriting it.

elsewhere he goes on to what's needed for that, also see the great both entertaining and informative fosdem talks about rejuvenating LibreOffice

feverzsj•about 1 hour ago

Try building google opensource projects. They'll be mostly broken on your own toolchain.

layer8•38 minutes ago

(2024)

Past discussion (653 comments): https://news.ycombinator.com/item?id=42231489

asmnzxklopqw•about 1 hour ago

I think that the steering committee currently considers that backwards compatibility has higher priority compared to strict memory safety. When the priorities will inverse then solutions will be found.

j16sdiz•4 minutes ago

When they inverse the priority, there are little reason to keep on using C++.

cherryteastain•about 2 hours ago

> Google supposedly significantly lowered its participation in the C++ development process, and instead started to work on their own C++ successor language.

Did they decide to keep things as is or rewrite in Rust with LLM assistance in the couple years since this article? Carbon seems to have gone nowhere.

tialaramex•12 minutes ago

Successor languages usually take a long time. Some of them are made by people who are bad at estimates and will grandly tell you that next year they will have finished the language, but that's just because they actually have no idea. In reality it's typically ballpark ten years.

Most programming languages "go nowhere" in the sense that they never end up used for lots of real world projects - but they can have interesting and useful ideas which inspire future languages.

Google writes a tremendous amount of new code. You can reap a large portion of the benefits by using Rust for new code.

aw1621107•about 1 hour ago

> Carbon seems to have gone nowhere.

At least as far as public info goes it's still being worked on. The GitHub repo [0] has pretty consistent activity and some recent-ish talks [1], one of which says that they are considering a 0.1 release "early next year".

[0]: https://github.com/carbon-language/carbon-lang

[1]: https://github.com/carbon-language/carbon-lang#2026

froh•19 minutes ago

https://github.com/carbon-language/carbon-lang/pulls?q=is%3A...

an active project indeed!

aureate•about 2 hours ago

(2024)