Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Two Factions of C++ (2024)

herecomesthemoon.net

Post reply on HN
Print view View original

21–30 of 89 posts

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

#21

Post by rhdunn »

pif wrote: post #19

> it’s at least a bitter awareness of the fact that the industry doesn’t care to refactor existing code Refactoring working, terrain-tested code?!? https://www.joelonsoftware.com/2000/04/06/things-you-should-...

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.

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

#23

Post by jstimpfle »

logicchains wrote: post #14
gignico wrote: 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.

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.

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

#24

Post by tialaramex »

mgaunard wrote: post #5

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.

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.

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

#25

Post by froh »

pif wrote: post #19

> it’s at least a bitter awareness of the fact that the industry doesn’t care to refactor existing code Refactoring working, terrain-tested code?!? https://www.joelonsoftware.com/2000/04/06/things-you-should-...

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

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

#26

Post by froh »

aw1621107 wrote: post #17
cherryteastain wrote: post #6

> 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

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

an active project indeed!

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

#27

Post by tialaramex »

cherryteastain wrote: post #6

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

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.

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

#28

Post by maleldil »

Rochus wrote: post #8
gignico wrote: 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…

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

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

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

#29

Post by tonyedgecombe »

>“We must minimize the need to change existing code. For adoption in existing code, decades of experience has consistently shown that most customers with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules, not even for safety reasons unless regulatory requirements compel them to do so.”

But the major players do seem to be happy to replace their C++ code with Rust.

Perhaps it's time to ease up on the backwards compatibility. Especially in the era of AI.

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

#30

Post by Rochus »

maleldil wrote: post #28
Rochus wrote: post #8

Earlier quoted context omitted.

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

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

Have a look at Qt implicit sharing. There is/was also a Boost library which could do most of it long before c++11.
Post reply on HN