from Hacker News

Overview: What are Cpp2 and cppfront? How do I get and build cppfront?

by cyber1 on 3/31/24, 9:26 PM with 168 comments

  • by Aardwolf on 3/31/24, 10:31 PM

    Unfortunately the first example already re-uses one of the less good parts of C++, the "<<" operator for std::cout, which always was a bit of a hack (including strange order of operations since << normally is left shift)

  • by jokoon on 3/31/24, 11:07 PM

    Someone on reddit said that the cpp2 repo was a bit old, and that is true, although he may have started this as an experiment influenced by typescript and left it on the side at some times.

    Anyway I have no idea if cpp2 would get support from microsoft or other devs, but cpp2 seems like the most humble and "least risky" solution for the future of C++, and I really want it to be.

    What I remember the most that Herb Sutter said in his cpp2 talk, is that it aims to avoid 95% of bad coding practices that C++ allows today.

    It's safe to say that beyond the valid criticism of C++, that it quite a good goal and it would improve C++, without using a new language, and that's good, because a new language causes problems: new toolchains, new semantics, new specifics, no experience on a new language.

    Cpp2 is not a new language, it is the same semantics of C++, except it has a new syntax and enforces good practices.

    One very interesting point: in the future, cpp2 allows a cpp2-only compiler to be born, and it would still live next to C++ binaries without problem. That cpp2 compiler might probably be much faster since the cpp2 is a smaller stricter subset.

  • by superamadeus on 3/31/24, 10:06 PM

    Is there any discussion or in-depth explanation of the syntax choices? I understand that a goal was context free unambiguous parsing. But there are some things that surprise me.

    For example, string interpolation:

        "Hello, (msg)$!\n"
    Why “(msg)$” and not “$(msg)”? Surely the latter is easier to parse?

  • by kreco on 3/31/24, 11:22 PM

    > // 'BufferSize' is an object defined as a synonym for the value 1'000'000

    > BufferSize: i32 == 1'000'000;

    So "value : i32 = 10" is variable, but "value : i32 == 10" is a constant.

    The difference is so subtle I'm not sure I like it.

    Later in the documentation you can find "equals: (a, b) a == b;" which is a function but it feels like I need to decipher it because "==" is not for alias in this case.

    Retaking the example of "equals: (a, b) a == b;" it feels also odd to omit the braces because they are even enforced for if/else branches.

    I have to admit that everything was interesting until the "Summary of function defaults" part.

  • by JNRowe on 3/31/24, 10:03 PM

    Sutter's 2022 cppcon talk¹ is a great introduction to the topic, both the problems it attempts to solve and solutions it was/is settling on. One of those few talks that left me genuinely enthused about the topic.

    [It is probably worth watching for the Compiler Explorer interjection toward the end alone -- Matt Godbolt Appreciation Society]

    ¹ https://www.youtube.com/watch?v=ELeZAKCN4tY

  • by grumpy_coder on 4/1/24, 5:01 AM

    It's a nice idea, but not clear that it can truly interoperate with vanilla C++ libs which I think is required. Seems to be waiting for modules to be finalized, but whether cpp2 can call cpp, and cpp can call cpp2 without implementing half of a C++ compiler isn't obvious. https://github.com/hsutter/cppfront/issues/594

  • by typ on 4/1/24, 2:41 AM

    Looks neat and convincing. But I think the goal (and effort) to make it into the C++ standard would hinder the momentum of adoption. I suspect it would have to go through a lot of politics and bikesheding before making any real-world impact. Imagine that if Typescript had insisted to get accepted into the Emca standard before widespread adoption and promotion by Microsoft; it would probably still stay in the 'experimental' stage.

  • by pciexpgpu on 3/31/24, 10:18 PM

    I wonder how this compares with Carbon -> C++ [0].

    Carbon is (was?) a fantastic proposal, but not sure if it has lost steam since it was introduced or how well it is being adopted (be it inside Google or outside)?

    Being able to incrementally/interchangeably use/call existing C++ code (and vice versa) seems like a great design choice (in Carbon) without having to introspect the actual generated code.

    Not sure how easy it is to get the cppfront-generated C++ to bridge with existing C++ code (and vice versa)?

    [0] https://github.com/carbon-language/carbon-lang

  • by dang on 3/31/24, 10:48 PM

    Related:

    Cppfront, Herb Sutter's proposal for a new C++ syntax - https://news.ycombinator.com/item?id=32877814 - Sept 2022 (545 comments)

    and also Cppfront: Autumn Update - https://news.ycombinator.com/item?id=37719729 - Sept 2023 (8 comments)

  • by kreco on 3/31/24, 10:32 PM

    > Because ++ and -- always have in-place update semantics, we never need to remember "use prefix ++/-- unless you need a copy of the old value." If you do need a copy of the old value, just take the copy before calling ++/--

    I actually wish ++ and -- operators were removed. This would simplify everything, nothing to remember whether it's prefix or postfix operator, whether it copies something or not, you would just do "value += 1" and be done with it.

    - Less mental overhead.

    - Remove an extra way of doing the same thing.

  • by darknavi on 3/31/24, 10:01 PM

    I know some of the arguments around C++/cpp2 are flawed, but I do love C++ and a project to move it forward with a step-change is exciting to me.

    A few of my friends and I did Advent of Code in cpp2 this year and it was a (very buggy) blast.

  • by suby on 3/31/24, 10:22 PM

    I spent the other day writing an archetype entity component system which made heavy use of template metaprogramming. I try to avoid this if possible, but it was an exercise in seeing how performant I could make it, and so I wanted to offload as much work as I could manage to compile time and avoid things like virtual dispatch. API similar to the basic parts of entt.

    My take away from the exercise is that this is not a language for human beings. I was successful in writing it, but it was extremely difficult and frustrating. Part of the frustration is because conceptually what I wanted to accomplish was not difficult, but figuring out how to express it was a nightmare. I am not new to the language, I've been writing C++ since 2009, it was the first language I learned and I've spent nearly every day of my life since then writing at least some C++ code. Even so, I can't say that I truly understand this shit.

    I'm hoping cpp2 brings us someplace closer to a language that mere mortals can understand. I don't want the next generation writing C++.

  • by skywal_l on 4/1/24, 9:36 AM

    In this kind of thread I always mentionned Circle[0] from Sean Baxter. It's worth a look.

    [0] https://www.circle-lang.org/

  • by dfgdfg34545456 on 4/1/24, 8:24 AM

    Great new idea in cpp. Automated bounds checking in the hello world example sold me straight away. Try and do that as tersely Haskellers. I hope this project gets momentum.

  • by howtofly on 4/1/24, 3:10 AM

    Any good CMake integration besides https://github.com/modern-cmake/cppfront?

  • by teo_zero on 4/1/24, 7:48 AM

    I like the idea, although many choices are arguable. For example, having to introduce mandatory/prohibited white space around binary/postfix operators (like "&") completely spoils the goal of having a more rational syntax.

  • by pjmlp on 4/1/24, 6:20 PM

    The whole story about what cpp2 tries to be, distancing itself from other C++ wannabe replacements is only due to be coming from WG21 chair, which naturally can't talk about a C++ replacement as per conflict of interests.

    Cpp2 isn't an alternative syntax to C++, as much as C++ and Objective-C aren't alternative syntaxes for C, even though they support a subset of it, and were born exactly the same way, code translators into C.

    C didn't evolve into them, they became their own ecosystem, tainted by the underlying C compatibility.

    The only alternative that is really a Typescript for C++, is Circle.

  • by ibobev on 4/1/24, 5:33 PM

    I do not understand why there is a push to change the C++ syntax. There are plenty of new natively compiled languages like D, Go, Rust, Zig, Nim, Odin, Crystal, and so on. If you do not like C++ you always can use some of them instead. The problems that make C++ unsafe are semantic and not syntactic ones.

  • by mgaunard on 4/1/24, 12:17 PM

    I don't want bounds-checking, so lost interest immediately.

    This is a step in the wrong direction.

  • by FpUser on 4/1/24, 12:18 AM

    Unless I can step through original source code in debugger, watch variables etc. etc. I could not accept any source to source translator in my practice.

  • by crazypython on 3/31/24, 10:26 PM

    What are the tradeoffs between cpp2 and Carbon?

  • by carlsborg on 4/1/24, 6:21 AM

    At this point the focus should be on making interop with python a first class feature.

  • by cies on 3/31/24, 10:05 PM

    Like Kotlin to Java

    Or ReScript to OCaml

    Or Gleam to Erlang

  • by colonwqbang on 3/31/24, 10:17 PM

    Most of my personal issues aren't with C++ syntax as such (although it also has many problems). My main gripes are:

    1. Very slow compilation.

    2. Poor encapsulation, adding private functions requires recompiling all dependents, see (1).

    3. Comically huge symbols make debugging much harder than it needs to be -- today gdb OOM'd my 16GB laptop when trying to form a backtrace of a typical QT application coredump.

    Unfortunately it doesn't seem like cppfront can fix these issues. It may still be a worthwhile effort in other respects, of course.

  • by fancyfredbot on 3/31/24, 10:41 PM

    It was when debugging a memory leak which occurred because I forgot to declare the base class destructor as virtual that I started to think C++ was a rather unfriendly language and not really designed to be easy to use.

    Then a few years later I read the spec for std::launder that I realised C++ was not really designed to be understood.

    It's a shame because it's actually a rather nice language in some ways. Here's hoping that this project or something similar takes off and separates the good bits from the bad.