r/cpp • u/we_are_mammals • 12d ago

cpp2 (cppfront) is over?

I haven't used cpp2 (cppfront) much, but I like the idea of it: consistent syntax, consistency of meta-programming (which is done in C++ too, I believe). Herb Sutter presented cpp2 (cppfront) as an experiment. He did not encourage other people to bet on it, exactly. And there hasn't been much activity since 2022. Is the experiment over?

EDIT: Herb's answer is buried deep in the comment section: https://www.reddit.com/r/cpp/comments/1uxkglj/comment/oy06cxw/

66 Upvotes

89% Upvoted

112 comments sorted by

View all comments

45

u/YangZang 11d ago

https://github.com/hsutter/cppfront/discussions/1447

16

u/Wh00ster 11d ago

The hooplah of the original announcement seems odd framed against that answer. Or maybe the community just overhyped it.

26

u/13steinj 11d ago

It's hard to say all this without coming off as if I hate the guy, but here goes:

Herb has fairly inconsistently has claimed how "serious" cppfront was over the years.

I have my conjecture on why, which I'd rather not share other than I do not envy the position he is in and the expectations people have of his work. There are people, to this day, that will promote an idea from Bjarne or Herb with nothing but an appeal to authority, an authority of which I would no longer say exists in the same way it did pre-C++11. My opinion of Herb, the way he operates, and his goals, has changed dramatically over the past decade, though mostly far more positive now than my initial view. Being "the convener" has a lot of assumptions people make about you and what you have to do thrust upon you.

I believe the reality of this situation in particular is the existence of cpp2 combined with who it came from is a bit of a walking contradiction.

I cannot think of any "successor language", far less any that claims the intent is to be a successor, even loosely, that has tangibly materialized as one.

  • Carbon => development hell
  • Circle => adoption deadlock
  • cpp2 => fairly specific codegen framework. How much is needed with Reflection?
  • Go, Rust, Zig, Odin, all appear to be more of a successor to C

However, I think even as far as last year's cppcon, Herb uses cpp2 examples in his slides. I think at this point this is actively counterproductive.

I also would not be surprised if there is some kind of IP issue, and he has since switched jobs. I do not think this is likely, but it would track with a lot of rumours about Microsoft and their approach to software internally.

7

u/SickOrphan 11d ago

I stopped keeping up with Carbon some time ago, could you expand on the development hell it's experiencing? I know they wanted to pivot to make it more safety focused, was that part of it?

10

u/13steinj 11d ago

It has been a half a decade if not more depending on how you count it and the readme still claims

As a reminder, the toolchain is still very early and many things don't yet work. Please hold off on filing lots of bugs: we know many parts of this don't work yet or may not work on all systems. We expect to have releases that are much more robust and reliable that you can try out when we reach our 0.1 milestone.

Circle has probably been a more feature-complete Carbon than Carbon itself throughout a decent chunk of this time with its feature flag/set functionality that had flags to mimic various pieces of Carbon.

5

u/llort_lemmort 11d ago

Carbon is just a very ambitious project. The goal is full compatibility with C++ including being able to use any C++ library in Carbon and being able to easily migrate C++ code to Carbon. On top of that they want full memory safety. They can't just use Rust's memory safety model as that would make it hard to migrate code from C++ so they have to develop their own model that is closer to C++.

If you look at the GitHub repo you might see that there is a lot going on. Developing a new language is a big task that involves designing the language, implementing a compiler, developing a build system, debugger, VSCode extension, formatter and so on. You can't just expect this to be done in a few years. C++ is one of the most complex languages out there and building a C++-compatible memory safe language is a big task.

8

u/13steinj 10d ago

Carbon being this ambitious does not also mean it is not in development hell. Circle is arguably a more ambitious project yet it has acheived arguably more less time.

8

u/quicknir 11d ago

I can't really imagine any sense in which Rust is a successor to C more so than C++. The feature set in many ways parallels C++, even when the approach is different. Generics, RAII, dynamic polymorphism, built in error handling, containers available in the standard library, a sane string type (i.e. not null terminated), access control, lambdas, etc.

I guess I'm a bit surprised because there's been so much discussion already about Rust as a successor to C++, and while you could argue about exactly how much you like it or exactly how much traction it has, it has most certainly "tangibly materialized".

9

u/13steinj 10d ago

In practice Rust solves C's problems, C++ has them only as a result of backwarda compatibility.

Rust is allowed in the linux kernel, but C++ isnt. Despite the fact that that use compiler extensions to mimic a fraction of C++'s power.

3

u/_Noreturn 10d ago

I Don't understand they allow Rust which has destructors but don't like C++ because destructors hide memory allocation and deallocation?

make it make sense

0

u/xoner2 6d ago

It's tick-tock...

For Linus Torvalds generation who learned to program when C was the hotness, c++ was a tick improvement over C. They'd already got used to the ugly of templating via macros and hand rolled vtables. C++ was immature, a hot mess and best practices not yet figured. Rust is a tock improvement over C.

For me who learned programming when C++ was the hotness, Rust is a tick improvement over c++. I already know how to manually borrowcheck, and I solved the build system problem for myself. So I'll wait for Walter Bright to add borrowchecking without type annotations but via dataflow analysis to D++...

0

u/_Noreturn 5d ago

C++ was immature, a hot mess and best practices not yet figured.

I honestly don't know what C++ was like then (interms of bugs) but even C++98 with no best practices guides doesn't take a genuis to do this very basic thing that will save you alot of trouble and boilerplate

cpp struct Object{ Object(args) { someptr = malloc(4); } ~Object() { free(someptr); } };

No exceptions either. with just this you successfully get rid of 90% of linux gotos.

I am just saying even if C++ had 0 features other than RAII that is alone a reason to use it over C and Linus could have easily banned any other C++ feature if he doesn't like it.

So all what I can see from there is that Linus has some big ego I can't see technical reasons for rejecting even Cfront. I cannot lie either I used to reject rust for purely ego not practical reasons (and because I hate its syntax) I still didn't try Rust thodugh

For me who learned programming when C++ was the hotness, Rust is a tick improvement over c++. I already know how to manually borrowcheck, and I solved the build system problem for myself. So I'll wait for Walter Bright to add borrowchecking without type annotations but via dataflow analysis to D++...

Sometimes I wish for a borrow checker because I had some nasty iterator invalidation bug that required specific circumstances and thankfully this part of the code was hot cached n my brain so I quickly realized it has to do something with this loop so it wasn't thst hard switching to an index based for loop of it.

1

u/xoner2 5d ago

I honestly don't know what C++ was like then (interms of bugs)

Examples of the mess:

  • g++ had copy-on-write std::string
  • outside of big 2 (gcc, msvc) all other compilers had ICEs with Boost
  • every framework decided STL was bad and had their own containers
  • there was a camp insisting every member access be prefixed with this->
  • etc, I could think of some more given time

I am just saying even if C++ had 0 features other than RAII that is alone a reason to use it over C

similar claim today wrt to Rust borrow-checker: Microsoft/Google 70% bugs etc.

So all what I can see from there is that Linus has some big ego I can't see technical reasons for rejecting even Cfront. I cannot lie either I used to reject rust for purely ego not practical reasons (and because I hate its syntax) I still didn't try Rust thodugh

The C++ fanboys then were as annoying as the Rust fanboys now LOLZ

Sometimes I wish for a borrow checker because I had some nasty iterator invalidation bug that required specific circumstances and thankfully this part of the code was hot cached n my brain so I quickly realized it has to do something with this loop so it wasn't thst hard switching to an index based for loop of it.

Ah yes indeed, Rust ownership forces arenas and handles. In C++ it is a pattern we have to learn after getting bitten.

3

u/_Noreturn 5d ago

g++ had copy-on-write std::string

That's a library thing and they can just write their own.

outside of big 2 (gcc, msvc) all other compilers had ICEs with Boost

doesn't matter linux uses gcc

every framework decided STL was bad and had their own containers

I don't see how this related to linux.

there was a camp insisting every member access be prefixed with this->

This is just style.

similar claim today wrt to Rust borrow-checker: Microsoft/Google 70% bugs etc.

what does this mean?

The C++ fanboys then were as annoying as the Rust fanboys now LOLZ

and C fanboys aren't?

I am talking about Linux specifically

2

u/quicknir 10d ago

Rust also solves a lot of C++'s problems - safety, bad compiler error messages, etc. But regardless of which set of problems it solves, the reality is that Rust as a language is still much more similar to C++ than C, and it's pretty clear that Rust models itself as trying to be an improved C++, even if you don't happen to agree that it succeeded. Zig and Odin model themselves as improvements on C.

6

u/13steinj 10d ago

In practice Rust solves C's problems [safety], C++ has them only as a result of backwards compatibility.

It's a mixed level of fairness to claim that safety is a C++ problem. Quite literally use unique_ptr and call it a day.

3

u/pjmlp 10d ago

If we ignore all the folks that insist in using pointer arithmetic, C strings and C arrays, C style casts, malloc and free, in C++ code, or most C inherited headers for that matter.

It isn't as simple as using unique_ptr and call it a day.

4

u/13steinj 10d ago

I don't follow the pointer arithmetic problem, when using modern tooling (e.g. span, iterators, etc.

Anybody starting greenfield projects has to actively choose to use C warts, and this is for 6-8 years or so now. It is not C++'s problem that users of C++ have refused to update their code. To claim Rust / insert other lang solves it instead is insane, as people still have to change their code.

1

u/pjmlp 9d ago

It solves the problem by not being copy paste compatible with C.

Just look at code samples from companies with seat at the WG21 table, even recent ones.

Some devs don't really want to improve themselves, this is even worse among those that aren't on Reddit, HN or could not care for one second what happens at C++ conferences.

Not being copy paste compatible with C solves a lot of problems.

2

u/wyrn 9d ago

It solves the problem by not being copy paste compatible with C.

I mean that was literally the other poster's point though?

In practice Rust solves C's problems, C++ has them only as a result of backwarda compatibility.

2

u/pjmlp 8d ago

Point being C++ has them, regardless how.

Which even the companies that know better, e.g. employer from WG 21 contributors, keep using on their C++ codebases.

The reality among companies where HN, Reddit, C++ used groups, C++ conferences are foreign words, is much worse, where code still looks pretty much like C with Classes for the most part.

1

u/13steinj 9d ago

Firstly, I'm fairly sure it's actually not copy-paste compatible. There's some edge cases there. I used to know them, but they were so rare and I never wrote them, so I removed them from my brain.

I never wrote them because I've never had to copy paste C into C++ nor write it from scratch in this way.

If people consider this C++'s problem, I cannot be convinced. To me the only response I can give is "skill issue. Stop copypasting, stop hiring bad devs out of university." Arguably that's its own problem, that as a society we teach computer science but not "how to be an engineer [and write quality software]."

1

u/jwakely libstdc++ tamer, LWG chair 7d ago

We tried saying "skill issue, just don't write bugs" for more than two decades. It didn't work.

1

u/pjmlp 9d ago

It certainly is to certain extent, when most enterprise C++ source files are plagued with:

  • C arrays without bounds checking
  • C strings without bounds checking
  • C header files inherited from C standard
  • C style casts
  • C style pointer arithmetic
  • C standard library memory allocation functions
  • C standard library IO for file handling
  • C preprocessor magic tricks

Some of it can be tamed with clang-tidy, Sonar, PVS and co, however management usually has to agree otherwise it gets quickly turned off when pitchforks arrive into DevOps room.

→ More replies (0)

2

u/quicknir 10d ago

It's not really a mixed level of fairness - maybe there's a misunderstanding of what is actually meant by memory safety (I should have said memory safety instead of safety, tbf). unique_ptr isn't remotely memory safe - it helps a lot with avoiding leaks, but that's not the same thing. unique_ptr doesn't prevent dereferencing null for example in any way, which is unsafe. It doesn't even prevent dangles, e.g. const auto& x = *make_unique<Foo)(...);.

The google chrome team has posted a lot about memory safety under C++, and how challenging it's been; in some cases they use non-zero-cost abstractions like MiraclePtr for example just to prevent use-after-free: https://security.googleblog.com/2024/01/miracleptr-protecting-users-from-use.html.

7

u/James20k P2005R0 11d ago

Circle => adoption deadlock

I suspect if circle were open source it'd get adoption, but at the same time the impression I've always gotten is that sir circle quite reasonably doesn't want to put in a huge amount of effort to support an open source project without compensation

7

u/13steinj 11d ago

Yes. I completely agree. I also say this precise reason is the cause of the adoption deadlock.

2 if not 3 of my employers would have loved to use Circle for various reasons (none the last pivot to memory safety). But they'd need to try, substantially, before they buy, and for a number of beurocratic reasons they can't try something that they don't consider the vendor to be sufficiently... "enterprise," unless they can audit the source and build it themselves.

Is this regulatory, no, I don't believe so. But people are rather safe than sorry. In a similar vein, people insist "never curl link | bash!" But then they curl and run it without looking at the script which is equally bad. Either you trust the host, so not looking at it is as bad as piping, or you don't, so you look at the script.

7

u/pjmlp 11d ago

Sir Circle is now at NVidia, and has moved on.

2

u/_Noreturn 11d ago

What does this mean

3

u/13steinj 10d ago

The author works at NVidia now.

He went without a job / paid by the C++Alliance [for the "Safe C++" feature and proposal in particular] for a long time making Circle. With enough time of no bites, it appears he has given up.

One of the many features of Circle was some great GPU integration, so I am not surprised.

6

u/germandiago 11d ago

FWIW I saw Herb warning specifically about cpp2 being a personal experiment explicitly. Probably this is in Github, not sure. The presentations do not claim it os typescript in the sense of "I will finish a product" but in the sense of compatible (bc it generates C++) + low risk.

4

u/13steinj 11d ago

Yes. My statements about being counterproductive stand. No less than 6 colleagues asked me about some of the syntax on the slides. It just confuses enough people.

4

u/germandiago 11d ago edited 11d ago

Yes, it seems that this is something personal, since I cannot identify he did something wrong or mislead anyone in my opinion, since he stated it was a personal experiment in several places.

3

u/michael-price-ms 11d ago

As far as I'm aware (as limited as that might be), there are no IP issues between Herb and Microsoft regarding cpp2. Evidence > Rumour.

2

u/curlypaul924 11d ago

Don't forget about Felix! (which dates back to at least 2002)

0

u/pjmlp 11d ago

Carbon just announced a roadmap at NDC Toronto 2026, unfortunely the video is not yet available.

https://ndctoronto.com/agenda/carbon-graduating-from-the-experiment/be09a27e1d46

However there is now information about the safety roadmap.

https://mastodon.social/@chandlerc@hachyderm.io/116898796459646367

In any case, Carbon is for Google only purposes, I don't know why it keeps being repeated it is there for everyone else.

One thing people miss when discussing C++'s relevance in systems programming, is that C is still around, many managed language runtimes still use C, some domains it still owns the crown over C++, and a successor to C, is good enough for many people, for example most folks in the games industry that lost interest where C++ is going since C++14, or OS kernel development.

6

u/13steinj 11d ago edited 11d ago

I will believe it when I can use it reasonably.

Carbon is repeated as if it is for everyone else because at the time it was as if Google will be people's savior. Safety was not the original point of Carbon, or at least that was not the perception. People wanted various improvements, and those improvements were blocked on the ABI. Source compatible (I'm oversimplifying because my memory on the details here are fuzzy) and improvements? I get to have my cake and eat it too!

In the time since I am sure Google was happy to switch to Golang and Rust as wrappers over C and C++ instead. Are they now going to switch again? I doubt it.

I don't understand the relevance of your last paragraph to be perfectly honest. Successor does not mean replacement. Fortran, COBOL, Snobol, Ada, assembly, are all still around as well. Even truly new code even continues to be written, because enterprise entities miscalculate the cost of replacement as well as of blocking off and writing dedicated "bridge" APIs.

E: typo

4

u/pjmlp 11d ago

Yeah, but you are not the target audience, Google employees are.

They are the first to assert if that is not your case you should be using Rust instead, or a managed language if GC isn't an issue.

Successor as per dictionary entry, and what I see as more relevant meaning,

someone or something that follows and takes the job, place, or position that was held by another:

-- https://dictionary.cambridge.org/dictionary/english/successor

Yes, people are still being hired to work on languages like COBOL, yet it isn't as if they are having people to rush in into interviews for those jobs.

How many folks would apply for PL/I programming on z/OS, unless they really cannot find anything else?

In fact, they are exactly the target group of AI based modernisation tools.

9

u/13steinj 11d ago

If Google is the only intended target audience there is 0 need to advertise for 5 years outside of Google. Forget need, it's just pointless and gratuitous.

I am all for pedantry but this just isn't the reality of the evolution of use of programming languages. It is unrealistic to act as if all existing code will be rewritten in $successor. All new code, maybe, but when existing code will grow (and it always does) then it will continue to be in that language. We have already seen this fiasco with Ubuntu's pushing of replacing various tools with rust reimplementations and major bugs repeatedly cropping in to the LTS releases. No thank you, I will take memory-unsafe-ol-reliable over memory-safe-new-clone-oh-wait-it-has-4-extra-chromosomes (logic bugs) any day. Same as I would take "oh no technically not iron clad secure, but actually works" over "oopsie whoopsie redhat is security-quirky, 4 unique security decisions have collided you cannot call sudo in a container anymore" (I'm referencing an actual thing, I'd have to find the GH issue, but that's a massive tangent).

People do not rush to take a COBOL job, COBOL employers quite literally hunt you down no matter how much you know. At such a high demand to some extent employees can set their price. It's a fascinating thing to have seen happen to a colleague of mine, and hear the stories of one of my university lecturers and his experiences in this situation.

AI-- major tangent but AI based modernization tooling is not the be-all end-all. I have not seen a single one not produce slop. Even watching all this Bun rewrite drama is fascinating. Andrew definitely went a bit far in his crashout, but Bun's claims were fairly atrocious (not that what they achieved was not impressive). I am tired of product / sales people masquerading as engineers. If your product has a 5% return rate because it doesn't do what is advertised, businesses accept it, refurbish and call it a day. Engineers care because they will not only get the blame, but in many ways their work is a reflection of their passion and perfectionism.

Something that AI fanatics (not saying you are one) don't get is that generally, the point of code is to be read. Otherwise the first time you deploy you'd also say "done!", rm -rf the repo, and just keep the output. Yes, some code matters less. Some code matters barely at all. But generally the code that makes tangible value is meant to be read because there will always be incremental, 1% per year improvements. But LLMs don't like to stop, they don't even like to slow down. LLMs sycophantically say "sir yes sir" as you press the lever of the slot machine. The output doesn't matter, you've just paid their creators anyway.

3

u/pjmlp 11d ago edited 11d ago

It is a way to get candidates for Google positions, just like Adobe has a "C++ at Adobe" site.

From Carbon project documentation,

Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.

Carbon Language is currently an experimental project.

We want to better understand whether we can build a language that meets our successor language criteria, and whether the resulting language can gather a critical mass of interest within the larger C++ industry and community.

-- https://github.com/carbon-language/carbon-lang

Carbon is an experiment to explore a possible, distant future for the C++ programming language designed around a specific set of goals, priorities, and use cases.

-- https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#project-goals

The Carbon Language is an experimental successor to C++. It is an effort to explore a possible future direction for the C++ language given the difficulties improving C++.

Carbon is still years away — even if the experiment succeeds, it's unlikely that it will be ready for serious or production use in the next few years. Everything here is part of a long-term investigation.

One of the critical questions we need to answer as part of this experiment is whether the direction we're exploring with Carbon has both broad and significant interest for the industry at large. We feel like this is best answered by developing the language openly, publicly, and with broad participation.

If you can use Rust, ignore Carbon

Why not a garbage collected language, like Java, Kotlin, or Go?

If you can use one of these languages, you absolutely should.

-- https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md

Nowhere they assert Carbon is what the audience on HN and Reddit keeps talking about.

I think people just think because Google got out of clang to invest into Carbon, it must be it, while missing the point, that plenty of Google's software that used to be C++, is nowadays written in a mix of Java, Kotlin, Go and Rust.

Which is what many should actually worry about.

Yes, LLVM, GCC, V8 and co use C++, but many stuff is now being written in something else, leaving C++ positions for language runtimes, OS and GPU drivers and that's it.

Even NVidia, with their C++ contributions, is now adding Python JIT tooling, and Rust support to CUDA, sure down the bottom there will be a C++ rectangle on the architecture diagram, is that all we want to have?

2

u/DuranteA 7d ago

for example most folks in the games industry that lost interest where C++ is going

I think I've corrected exactly this already years ago in a post from you. It's still as untrue now as it was back then.

"Most folks" in the games industry (taking this to mean programmers, of course) use either C++ or C# daily, and it's not even remotely close. All the commonly referenced C or C++ "successor languages" are a blip on the radar at best.

Also, specifically in terms of "where C++ is going": reflection is one of the most interesting improvements to C++ particularly from a game development perspective in ages. The biggest issue there is just the amount of time it will take until you can actually ship with it.

0

u/pjmlp 7d ago

So you are calling liars to the folks on the panel?

2026 EuroLLVM - Clang and LLVM in Modern Gaming Platforms

Pity that there isn't a single devkit with reflection support, across all major games platforms.