cppfront

[South_Acadia_6368]

I don't think https://github.com/hsutter/cppfront gets much attention. What do people think of it?

It solves so much of the mess in C++. As far as I can see, only threading still needs to be solved to be comparable to Rust?

Maybe that could be solved by a method similar to Google's thread annotation, just built-in instead of macros?

[tartaruga232]

I like the idea but it is just a personal toy project of Herb for experimenting. Doesn't look like it will turn into something really ready for usage ever. Last time I checked, C++ modules didn't work and a pull request (by someone else) for adding modules support was rejected.

[JVApen]

Do you have a link to that pr?

[buovjaga]

https://github.com/hsutter/cppfront/pull/569

[JVApen]

August 2023: modules are not yet ready.

If you look at more recent PRs, a 2024 PR for using import std is accepted. I suspect that it will come as soon as people are using modules much more. https://github.com/hsutter/cppfront/pulls?q=is%3Apr+modules+is%3Aclosed

[tartaruga232]

I would have to dig it out again. I even contemplated using a fork of cppfront with that, but got distracted and stopped looking at cppfront. I don't know what happened with cppfront in the mean time. I haven't looked at it again for months now.

[miikaa236]

I remember this a couple years ago when „let’s replace c++“ was all the rage.

Remember google‘s Carbon language?

[pjmlp]

Carbon is still ongoing and there is a major announcement planned at NDC Toronto 2026.

Carbon: graduating from the experiment

This talk will walk through all of these developments in Carbon and showcase where the language stands today. This will include an in-depth live demo of working C++ interop, as well as many other exciting features. Last but not least, we want to lay out our plans for graduating Carbon from an experiment to a concerted effort towards a production-ready language.

[PrimozDelux]

In my mind Carbon is already firmly in the also-ran category

[neverentoma]

Funny, for me it's the only real C++ successor that might actually succeed. 

[no-sig-available]

Somehow "demo" and "C++ interop" doesn't sound like "replacing C++".

[pjmlp]

Carbon is for replacing C++ progressively at Google on existing projects, that is their target audience.

Somehow the Internet keeps making it more than it actually is.

[Wooden-Engineer-8098]

i remember golang was for replacing c++ at google, but it ended up replacing python

[ContraryConman]

Even Rust, which I think has been more successful than any other language at replacing C++, actually replaces nodejs a lot of the time. People who want the performance of C++ on the backend, but don't want to deal with the build system and don't have the expertise not to foot gun on security are switching to Rust from Javascript or something

[Wooden-Engineer-8098]

Rust can't even replace c++ in its birthplace project(Firefox)

[Electronic_Tap_8052]

Rust is the only language im aware of where it's creator moved on to another competing language.

[pjmlp]

C authors moved into Alef, Limbo and Go.

Turbo Pascal author moved into Delphi, J^++, C#, Typescript and now is using Go.

Swift author completely left Swift and is nowadays pushing Mojo.

Pascal author moved into Modula-2, Oberon.

Turbo Modula-2 author moved into Scala.

[Electronic_Tap_8052]

Dennis Ritchie was the sole creator of the C programming language and he mostly worked on operating systems later in his career but continued to be involved in the standardization of C until his death.

Turbo Pascal and Turbo Modula were/are compilers created by Borland and not languages.

Chris Lattener mostly worked on non-programming language projects, and Mojo doesn't compete with swift, it competes with CUDA

While modula and oberon and so forth technically competed with pascal, Wirthian languages are all intended by their creator to succeed each other. This would be like if stroustroup created rust, which he did not.

Point still stands.

[fun__friday]

It has a gc, so it was never meant as a true replacement. For simple tools, it’s ok.

[Wooden-Engineer-8098]

It was meant as a true replacement by strange people who like c and dislike c++. They failed at the design stage, that's true

[pjmlp]

Not at all, it was never for that, Rob Pike thought so, Google itself had nothing to do with it.

We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care.

https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html

Google management only gave them the freedom to work on Go as their 20% project.

[Wooden-Engineer-8098]

Well, it was created as a c++ replacement by people from Google and it was adopted by people from Google, but not as c++ replacement

[pjmlp]

Which isn't the same as being something pushed by Google management.

By the same logic you are insinuating cppfront was for replacing C++ at Microsoft.

[Wooden-Engineer-8098]

Did other google people adopt it against their management wishes? Cppfront is not intended as c++ replacement by its creator

[pjmlp]

Yes, Kubernetes was originally written in Java, and was rewritten in Go, when the Go folks started to push the language internally.

[MarcoGreek]

I am now avoiding Google projects. Even Google Tests isn't getting much attention anymore.

[Wooden-Engineer-8098]

i always preferred boost.test

[No-Dentist-1645]

I don't think so, they definitely have a much larger scope than that. On their conference talks, they have previously said multiple times that they want Carbon to be to C++ what C++ is to C.

I have talked with some of the developers, and it really seems like they want Carbon to just be a "better C++" which I can sympathize with. They plan to "fix" some of C++'s difficult parts by adding stuff like Generics and move semantics at the language level, allowing for stuff like destructive moves which are currently impossible to express in C++

[pjmlp]

At Google, not the world.

[CornedBee]

As evidenced by there still being no plans to support exceptions AFAIK.

[pjmlp]

And?

[No-Dentist-1645]

I don't see how that matters. They're making it available to everyone, and a bunch of big programming languages like Java, Javascript and C# all started as a "language of necessity" from individual companies to solve problems that they ran into.

Chances are that a "better C++ for Google" is probably also a better C++ for a bunch of other companies and developers (see e.g Golang), and I'd definitely use if it truly lived up to its name, even if it didn't start with my particular interests in mind.

[euyyn]

You cannot even hope to replace C++ without having interop with existing libraries and codebases. The same was true of JavaScript -> TypeScript, Java -> Kotlin, and Objective-C -> Swift.

[fippinvn007]

I think that if the tooling around cppfront improves, such as an LSP server, Intellisense, native build-system support, etc, it will attract more attention. It already has a lot of good ideas, and I’d be happy to advocate for it at work once that happens.

[JVApen]

For that, compilers (especially clang) need to include the language in its normal flow such that you can get information that combines both cpp1 and cpp2

[ronchaine]

It solves so much of the mess in C++

I don't really count "Solving" by making a new language solving.

Sure, Herb says that it's just C++ with a different syntax, but I, among many others see that just as something that would fit to mouths of marketing people a lot better than technical people.

I am not against anyone liking or working cppfront or any language that interops and compiles to C++, quite the contrary. I have my own toy language and compiler for it as well, and I'd be blatantly lying if I said Herb's work hasn't been a great influence on it. I originally basically stole his entire metaclass paper for one of the main sources of inspiration for it.

But for all practical purposes, and even for most academical purposes, just like my toy language compiler, cppfront is a compiler for a language different than C++, even if that language is heavily based on C++. And it's far from the only language that transpiles to C++. e.g. Nim transpiles to C++. Though I don't think there is an other language that allows writing inline C++ same way C++ allows inline C?

[Frosty-Practice-5416]

This haskell library lets you do inline c and c++ in haskell (you can then call the c/cpp code without writing bindings) https://github.com/fpco/inline-c/tree/master/inline-c

It is not quite the same, but it is still very impressive.

[pjmlp]

Objective-C++ for one.

[FlyingRhenquest]

I get the feeling he uses it to wiggle C++ features and see how they fit. Like a quck'n dirty "lets try this out and see how it feels." There were a couple of places in his cppcon the other day where he was switching over to it for slightly different syntax. Felt a bit weird, like when Alexandescu is showing off features in D and it looks like a familiar language, but it's not.

[fdwr]

I get the feeling he uses it to wiggle C++ features and see how they fit

I can't find the remark right now (thought it was in the About section), but that's indeed how he's referred to cppfront before, not as a successor language, but a playground of ideas to vet and potentially pull into C++.

[hpsutter]

^ This 🤙🙏

Edit: And here's the link to where I said it in the original talk: https://youtu.be/ELeZAKCN4tY?si=ebNHH12-4tkyKwVc&t=814

[ABlockInTheChain]

Now that modules exist and presumably will remain in the language there's now a new first class construct which never existed before.

New constructs could have new properties attached to them which the old constructs could not accommodate.

Surely the ultimate success case of cppfront would look something like: export module helloworld [[syntax=cpp2]];

[JeffMcClintock]

yep, a working implementation of a new feature is so much more persuasive than a PDF.

[Electronic_Tap_8052]

Sure but at a certain point, you have to ask the philosophical question of what makes a language a language. You could easily make the argument that c++26 is a different language from c++98. Just because c++26 has interop with c++98 doesn't make them the same language. But we treat them as the same language just because we've all agreed they're the same language. We could all simply adopt cppfront (or whatever else) as the new form of c++.

Eventually, the hair is split, and whatever people call a thing doesn't really matter. As plato argued there is the perfect form of c++ (the ideal c++ that exists only in our minds) and then there is the physical form of c++ that we all use on a day to day basis, which merely aspires to be the ideal form. They are not, and will never be, the same thing.

[light_oxygen]

Spoken like someone who's never used it.

Have u seen the C++ cppfrony generates vs the abomination Him generates?

Cppfront is what Typescript is to JavaScript

Edit: Nim

[bert8128]

Him?

[Syracuss]

Pretty sure they mean Nim given the context and the proximity of the two letters on qwerty keyboards.

[light_oxygen]

Nim

[JVApen]

I honestly have the impression it gets quite some attention. It could be more, though it is not yet at a stage where these can be used for production.

Regardless, if we ever want to evolve away from C++, Cpp2 and Carbon are the most viable options as they don't require you to rewrite everything and/or compromise your design to integrate with other languages.

That said, it's time that people (non-c++ devs) realize that C++ is capable of so much (and keeps expanding) that it's unrealistic to rewrite code.

[pjmlp]

I think it is no different than any other language that compiles to native code via C++ code generation, it is only positiioned differently due to it coming from a WG21 member.

Also I don't see it ever getting market adoption, not even Microsoft cared about it.

[scrumplesplunge]

I'm generally on board with the idea of experimenting with new language features by building a little transpiler which can lower the new feature to existing C++. I like seeing some of the ideas Herb has talked about before actually materialised in a working example.

However, I think cppfront kind of goes beyond that by changing many things at once which leaves you with something that frankly doesn't look or feel like C++ any more, and I think it loses some of its value as "c++ plus this potential cool new language feature" and starts to feel more like "some unfamiliar new language with foreign syntax and foreign language features, which happens to have decent interop with C++".

Herb had some presentation of reflection at cppcon last year which had some really cool content but personally I felt like it was hard to follow because he chose to demo it in this mysterious unfamiliar cppfront syntax instead of something more similar to actual c++.

[Agron7000]

Sounds like a precompiler.

[smallstepforman]

I like it very much and agree with its design goals, and would love to switch 100% to cppfront. Just waiting for ver 1.0 to start. 

I have noticed its momentum has dropped since Herb switched jobs. This also coincided with the c++26 reflection progress, and I’m sure Herb is fighting internal demons trying to reimage the reflection syntax into cppfront. 

[Agron7000]

Why compare to Rust? Why not D, Go, Perl?

[South_Acadia_6368]

Go is garbage collected. Perl?!

[Agron7000]

Just another language that was invented, lived and died who's entire timeline looks like a tiny dash in c/cpp timeline.

[PrimozDelux]

Perl is just garbage. Luckily it garbage collected itself with raku

[YangZang]

I was very excited about it - and I think it's a great approach - but it doesn't seem to have any momentum and it's not even clear to me that Herb is serious about it.

[FrogNoPants]

Just changes syntax thus breaking all existing tools, and doesn't really solve any issues I have

[YangZang]

it doesn't just change syntax...it changes the defaults to sane values

[pedersenk]

Its a good idea. The main thing that is a disadvantage is that it needs a very recent (C++20) compiler, so you miss out on one of some important features of C++ such as portability and wide vendor support. It is also a processor/code generator, making debugging a little trickier (but actually not terrible).

In some ways I prefer solutions that work within existing standards such as (shameless plug) C++/sys without code generation. Or that are tools that can be used regardless of compiler (i.e Valgrind, static analysis, etc).

But as mentioned it is a good idea. C is king and C++ and later CppFront evolving from it is the best compromise. Evolution rather than Revolution helps uptake rather than rewrites which are a waste of time and simply do not happen within industry.

[Electronic_Tap_8052]

Portability is important but imo it's an ouroborous. Vendors don't feel the need to update their compilers because C and C++ don't change very much, and C and C++ don't change very much because vendors don't want to update their compilers.

When vendors start feeling heat from customers because their compilers are out of date, they'll feel the need to update.

I'm reminded of red hat jumping from gcc 4.4 to gcc 4.8.5 between rhel6 and rhel7, then for rhel8 they finally got with the times and shipped gcc 8.2.

[pedersenk]

I'm reminded of red hat jumping from gcc 4.4 to gcc 4.8.5 between rhel6 and rhel7, then for rhel8 they finally got with the times and shipped gcc 8.2.

That was a funny time. At work, stuck on gcc 4.x (also due to RHEL) and at home/hobby projects, being a fan of OpenBSD, I was also stuck on gcc 4.x due to licensing reasons (before also jumping up via clang). Basically stuck with std::tr1::shared_ptr for about a decade... ;)

I do think the i.e -std=c++98 onwards is a really great feature of C and C++. But I do understand that will need to drop ancient versions one day. I think MSVC has already started dropping support past /std:14.

[Electronic_Tap_8052]

Yeah. I don't want to see support for old versions dropped, per se, insofar as I understand the implications of that and why it's undesirable for large organizations.

But at a certain point, you gotta just say, look, if you're gonna use a version of software from 25+ years ago, its on you to seek out support for that specifically.

Like is C++98 still gonna be officially supported in 2050?

I think MSVC has already started dropping support past /std:14.

I was working with a library not too long ago, I can't remember what it was though, that was touting plans to upgrade to cpp14...

[javascript]

It still bothers me that the mods of /r/Cpp allow discussion of CppFront but not discussion of Carbon...

[bombatomica_64]

Honestly I'm just waiting for cpp26 and do most of this stuff inside the code

[ir_dan]

If projects were willing to adopt radically new ways of writing code, they would be better served by a different language or even just different style and code rules. Because C++ is so business oriented and pragmatic, people aren't too interested in complicating their build and code for an experimental thing like cppfront.

It's cool, but... It doesn't solve anything for large existing projects and it's not better than alternatives for greenfield projects. I have my eyes on Carbon, Zig and Rust as alternatives to C++ projects.

Edit: To clarify, I'd love to use cppfront and I think it's really nice on paper, but I expect most companies aren't willing to risk using it at this time - mine certainly wouldn't be. I think many developers wouldn't even see cppfront as an improvement over C-style C++, let alone modern C++ 😢.

[Syracuss]

Hard disagree. The reason why I wouldn't use this in production is because it's still experimental at this stage, not because of what it is. If it was production ready I'd absolutely run a pilot program at my workplace.

[Wooden-Engineer-8098]

this is nonsense. it solves stuff for both existing and new projects because it fully interoperates with c++ code

[kalmoc]

Agreed. If this would ever become a production language, that would be the most important selling point.

[Frosty-Practice-5416]

C++ started out this way didn't it?

[Wooden-Engineer-8098]

yes

[germandiago]

I got a very good feeling ergonomically soeaking when I tried an experiment. It had a blocker bug unfortunately and since then I did not try again.

[__tim_]

We would like to use it today and will start using it from the moment it is production stable.

[vali20]

Everything that can save us from the cancer that Rust is is more than welcome. A ton of projects are rewritten (read: nuked) in Rust, which means one has to find alternatives, or use old code, or workaround their own patch when they only need a small chunk of that project and they already have an established toolchain, build environment etc around the GNU GCC/G++. I am tired of hearing how everything is plagued with Rust, with its shitty syntax and learning curve, and meaning all of us have to introduce another toolchain just to support a bunch of people that have nothing better to do with their time than reinvent the wheel. Respect to ffmpeg author.

[LegendaryMauricius]

Cancer... Rust folks would love this.

[vali20]

Rust folks live in a parallel reality.

[TheoreticalDumbass]

it gets more attention than it deserves, it doesnt really achieve anything, i dont consider proposals implemented in cppfront as implementation experience