Live data from Hacker News

The Two Factions of C++ (2024)

herecomesthemoon.net

11–20 of 89 posts

Re: The Two Factions of C++ (2024)

#11
post #3
post #2

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…

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-to…

> 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

Re: The Two Factions of C++ (2024)

#14
post #3
post #2

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…

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-to…

>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.

Re: The Two Factions of C++ (2024)

#15
post #3

Earlier quoted context omitted.

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-to…

>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.

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)

Re: The Two Factions of C++ (2024)

#17

> 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.

> 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

Post reply on HN