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

61–70 of 89 posts

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

#61

Post by dundarious »

tialaramex wrote: post #24
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 de…

Look no further than DJB's troubles: https://blog.cr.yp.to/20260814-update.html

Probably best to go to the index and look at part 1 of the saga.

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

#62

Post by lelanthran »

flohofwoe wrote: post #44
YuechenLi wrote: post #41

Earlier quoted context omitted.

Carbon isn't even a real language, no real language will spent 4 entire years and is still stuck in version 0.0.0-0. It feels more like bad Rust than a proper C++ successor at all. Just to give you a small example? why would a C++ successor language use `fn main()` instead of using C/C++ style `int main()`? And their generics system is even more confusing, are they going to support a new form of generics or are they…

> why would a C++ successor language use `fn main()` instead of using C/C++ style `int main()` Apparently easier and faster parsing. Most modern language have arrived at the `fn bla(arg: ArgType): ResultType` form and I don't think they made that decision for purely aesthetical reasons.

> Most modern language have arrived at the `fn bla(arg: ArgType): ResultType` form and I don't think they made that decision for purely aesthetical reasons.

Not just modern, it's older than you think. Pascal function definition is `function bla(arg: ArgType): ResultType;`

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

#63

Post by locknitpicker »

tonyedgecombe wrote: post #29

> “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 wi…

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

I would be wary of mindlessly referring to appeals to authority like this. Sometimes their rationale is very context sensitive. For example, Microsoft has been behind quite a heavy push for C#, and it wouldn't be wise to use that as an example of C# being preferable to C++. See for example Bun's recent migration to Rust which could be misinterpreted as an example supporting migrating to rust, but under the hood it's far from a success story.

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

#64

Post by HarHarVeryFunny »

There is a natural tendency for all programming languages to want to both retain backwards compatibility and also accumulate new features, eventually outgrowing the original design. C++ is obviously well past this point.

If this was a code base rather than a language specification, then this would be the time to refactor, but with a programming language you've got a world full of code, compilers and tools, and the resistance to change is massive.

One of the few success stories of a language refactoring and dropping backwards compatibility is Python 2 -> Python 3 (a 10+ year struggle). What might be considered as a failure case is Perl 5 -> Perl 6, where resistance to change caused the migration to Perl 6 to be so slow that effectively Perl 5 won, and the language itself became obsolete.

So, be careful for what you wish for - C++ certainly needs a refactoring, but whether it could survive it is another question, especially now since backwards compatibility is what is keeping it alive in the face of competition, and it's not at all clear going forwards what the impact of AI on programming languages is going to be.

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

#65

Post by aw1621107 »

jcranmer wrote: post #59
logicchains wrote: post #14

Earlier quoted context omitted.

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

I'm not sure C++26 reflection is sufficiently well-baked to actually allow it to be used for serialization boilerplate in codebases. What matters is not what the standard says, but what the compilers implement, and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.

> and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.

Out of curiosity, would you be able to elaborate on (or link to?) what makes reflection so problematic?

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

#66

Post by lelanthran »

flohofwoe wrote: post #42
lelanthran wrote: post #37

Earlier quoted context omitted.

> There is a good language buried underneath C++ somewhere, it's just that nobody has taken the time to extract it. Carbon?

No, it's C :) And for me that's not even a hot take anymore, I switched back to C (specifically C99 and later) around 2017 after nearly 20 years of C++ as my main language, and I don't miss C++ the slightest. The hardest part was unlearning some bad C++ habits. The other 'behaviour change' for me was to open my mind to more programming languages. E.g. instead of trying to solve every problem with C++ I now pick a lan…

> No, it's C :) And for me that's not even a hot take anymore,

For me, I switched away from C++ in 2008 or thereabouts. For anything that needs a higher level of abstraction than C, I'll use Lisp, Python, Java, C#[1], etc.

You might enjoy (shameless plug to my own blog):

https://www.lelanthran.com/chap9/content.html

https://www.lelanthran.com/chap13/content.html

=============================

[1] Although, C# has lately gone the way of becoming incomprehensible syntax-wise. I've seen this happen with C++ in the past, so not so sure I'll even use C# again.

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

#67

Post by aw1621107 »

YuechenLi wrote: post #50
HappMacDonald wrote: post #40

Earlier quoted context omitted.

> There is a good language buried underneath C++ somewhere Well.. "C".. though I wouldn't go so far as to call that a good language, either.

Well, Carbon would have been better off if they just made "C with `match` and sane error handling" instead of whatever it is they are building there over at Google. But still, I think C and C++ are honestly very different languages at this point and that you can't really call C++ a superset of C at all really.

> Well, Carbon would have been better off if they just made "C with `match` and sane error handling" instead of whatever it is they are building there over at Google.

Perhaps that might be a better language in a different context, but I don't think that language would have have been better for Google given their goals (e.g., bidirectional interop with C++, incremental automated migration, memory safety, etc.)

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

#68

Post by simon_void »

locknitpicker wrote: post #63
tonyedgecombe wrote: post #29

> “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 wi…

> But the major players do seem to be happy to replace their C++ code with Rust. I would be wary of mindlessly referring to appeals to authority like this. Sometimes their rationale is very context sensitive. For example, Microsoft has been behind quite a heavy push for C#, and it wouldn't be wise to use that as an example of C# being preferable to C++. See for example Bun's recent migration to Rust which could be mi…

> Bun's recent migration to Rust which could be misinterpreted as an example supporting migrating to rust, but under the hood it's far from a success story.

Since you don't mention that this migration is basically executed agenticly by Claude, it seems like you attribute this troubled migration to Rust not being that good of an improvement after all. For me it doesn't seem that surprising that Claude autonomously translating hacky Zig (according to Andrew Kelly #1) to unidiomatic (way more unsafe code that usual) Rust didn't solve the issues that the original code base already had.

#1 https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...

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

#69

Post by neutronicus »

abbefaria27 wrote: post #56

To be fair to the committee, upgrading C++ compilers is already a chore, even with the changes as small as they are. Would you rather spend time updating your lambdas because they changed how capture works (a real breakage not long ago), or doing something of actual value? The only reason we finally updated from Python 2.7 to 3 was that the OS vendors dropped it, but it was effectively a waste of time. That aside, I…

The application I work on has an extension API that only requires C++11, but we compile against all the same headers in C++20.

Obviously we need ABI compatibility between the two standards for this to work.

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

#70

Post by budman1 »

You folks are in an HN bubble.

C++ is still king of the mountain and it will remain so for decades.

The billions of lines of existing C++ are not being re-written in rust (by humans or AI's). 100 thousands of lines are being re-written.

C++ is changing, but C++11 is moving across the land. It will be 20 years before the 'new' C++ stuff gets regularly used.

Just because it is old, doesn't mean it doesn't have value.

Just because it is done a certain way at google, doesn't mean you have to do it that way.

Post reply on HN