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

81–89 of 89 posts

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

#81

Post by pornel »

blub wrote: post #79
pornel wrote: post #51

Earlier quoted context omitted.

> But the major players do seem to be happy to replace their C++ code with Rust. Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched. It's not worth to rewrite C++ into C++++ to get a couple of features that are flawed retrofits backported from modern languages. In the end you still have C++.

The set-up and your reply feel like a Rust sketch. Not touching a codebase only applies to legacy software which is feature complete. Any actively developed software will benefit from incremental improvements. Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golan…

Note that an incremental language improvement doesn't mean a small code change. For example, C++'s iterator with two related but technically independent pointers is a PITA for alias analysis, which is a problem not only for Circle/Safe C++ but for WG21 Profiles too (https://www.circle-lang.org/draft-profiles.html). An incremental language change would be to adopt a Rust-like iterator. That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.

Bjarne still sees C++'s safety problem as lack of adoption of Modern C++. WG21 is catering to C++ users who will not make such changes.

WG21 has firmly rejected everything resembling Rust's borrow checking (a solution that now has a decade of proven track record, and has been demonstrated to be possible in C++ via Circle/Safe C++). Addition of "pervasive annotations" is so unacceptable to WG21's view of C++ that they're still insisting on Profiles.

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

#82

Post by rpnx »

This is why I'm building Quxlang.

C++ cannot evolve easily without breaking backwards compatibility.

I started Quxlang because I saw the writing on the wall for C++. Doesn't mean C++ isn't good, but it has issues and needs improvement.

Somehow I managed to implement working modules, C++ doesn't seem to have that yet, although the C++ build system is horribly broken.

We'll have to see how it compares when it's more complete and ready to use. I don't have oop/inheritance yet which is also important for a C++ alternative.

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

#83

Post by rpnx »

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.

Worth noting, Carbon is just an experimental language, I see no evidence it's being used widely or replacing C++.

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

#84

Post by rpnx »

YuechenLi wrote: post #41
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?

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…

> no real language will spent 4 entire years and is still stuck in version 0.0.0-0.

Strongly disagree. I too thought that it would be easy to implement a new language in 1-2 years. I started the current Quxlang codebase (under a different name) on Dec 27, 2022. In 2026, hundreds of commits and hundreds of thousands of lines of code later, I still don't have a feature complete language.

I also rewrote the syntax, mainly because C++ parsing is a nightmare... Although my choice was very different...

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

#85

Post by maleldil »

Rochus wrote: post #30
maleldil wrote: post #28

Earlier quoted context omitted.

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

That's not the same as smart pointers like std::unique_ptr.

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

#86

Post by Rochus »

maleldil wrote: post #85
Rochus wrote: post #30

Earlier quoted context omitted.

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

That's not the same as smart pointers like std::unique_ptr.

Have a look at boost::movelib::unique_ptr which works well with C++98/03.

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

#87

Post by rpnx »

YuechenLi wrote: post #36

In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad, because I swear I spent 2 days trying to setup CMake to get Skyrim modding setup, and in the end, I had to tap ou…

Disagree. There are important things C++ gets "right" that languages like Go, C#, Java, and Rust get "wrong". It's difficult to impress these ideas on people who dislike C++, because they are largely not willing to learn C++.

The C++ build environment is awful, I'll give you that much.

I find people tend to fall into two camps, people who don't understand C++ because it's "too complicated" and people who like C++ (though acknowledge the syntax is a bit odd sometimes).

Extraction of the essence of C++ is ongoing...

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

#88

Post by rpnx »

locknitpicker wrote: post #55
YuechenLi wrote: post #36

In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad, because I swear I spent 2 days trying to setup CMake to get Skyrim modding setup, and in the end, I had to tap ou…

> In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I don't think that professional developers go around mindlessly starting projects without evaluating their choices. The truth of the matter is that the whole industry has been picking C++ over alternatives for ages, to the point where C++ managed to get one of the most popul…

The C++ environment for builds is kind of awful. It's usable, but extremely complicated, non-uniform, and rarely well implemented.

CMake isn't a good build system, it's just the least bad one we have.

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

#89

Post by blub »

pornel wrote: post #81
blub wrote: post #79

Earlier quoted context omitted.

The set-up and your reply feel like a Rust sketch. Not touching a codebase only applies to legacy software which is feature complete. Any actively developed software will benefit from incremental improvements. Quality C++ projects continuously improve their code and tooling. It would be very convenient for the rustafarian community if the competition stood still, but that’s not the case. Quite happy to see that golan…

Note that an incremental language improvement doesn't mean a small code change. For example, C++'s iterator with two related but technically independent pointers is a PITA for alias analysis, which is a problem not only for Circle/Safe C++ but for WG21 Profiles too ( https://www.circle-lang.org/draft-profiles.html ). An incremental language change would be to adopt a Rust-like iterator. That would be a small language…

“Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched.”

That was most of your original comment and it remains wrong.

Now you’re talking about specific memory-safety-related features, but you’re making a big assumption. Not everything has to look like Rust. Goodness no! And C++ is still improving in that area too.

“An incremental language change would be to adopt a Rust-like iterator.” One of many possibilities.

“That would be a small language change, but a migration away from begin/end would be a massive churn for C++ codebases that sounds more ridiculous than rewriting in Rust.” Obviously not. Nowadays maybe it could be easily done with AI, even if a Rust-like iterator is not necessarily something that C++ programmers would want.

Post reply on HN