Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The first new build of Circle, a new C++20 compiler, since April 2022 is online

github.com

Post reply on HN
Print view View original

11–20 of 80 posts

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#11

Post by fidgewidge »

erik_seaberg wrote: post #5
pjmlp wrote: post #4

From all possible wannabe be replacements for C++ that poped up in 2022, Circle is definitely the one that has the most going for it. Everything else requires rewriting everything, and they can only support a limited subset of C++ features, so if the goal is full compatibility with existing code they aren't going to achieve it anyway. For full rewrites, we already have enough alternatives with more maturity years beh…

This lays groundwork for opt-in safety per file, but safety should affect API design. Once you get done doing this to every file and refactoring every public API, have you really spent less effort than would have gone into a rewrite? If you only get halfway there, is the new version going to blow up any less often?

Kotlin managed it in some cases with clever forwards compatible type system tricks, so it's not impossible

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#12

Post by carabiner »

rogerclark wrote: post #3

Truly an amazing project. One person implementing the entire C++ standard, and then countless new, useful features on top of it. Circle did the interpreted, compile-time pass idea before any of the other new systems languages. Carbon and C++Next both seem very directly "inspired" by Circle, but neither of those efforts seem to have actually produced anything yet. Ideally, Circle it would be open source. But I underst…

He seems like a wonderboy. His linkedin has a recommendation: "Cannot say enough good things about this guy--probably the most capable programmer I've ever met."

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#13

Post by pjmlp »

fidgewidge wrote: post #11
erik_seaberg wrote: post #5

Earlier quoted context omitted.

This lays groundwork for opt-in safety per file, but safety should affect API design. Once you get done doing this to every file and refactoring every public API, have you really spent less effort than would have gone into a rewrite? If you only get halfway there, is the new version going to blow up any less often?

Kotlin managed it in some cases with clever forwards compatible type system tricks, so it's not impossible

Except it does so by compiling into the same bytecode as Java, javap will just output Java like code from class files, and some stuff like co-routines cannot be called from existing Java code without wrappers that setup the runtime semantics as expected by Kotlin libraries.

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#14

Post by pjmlp »

anonymoushn wrote: post #7
rogerclark wrote: post #3

Truly an amazing project. One person implementing the entire C++ standard, and then countless new, useful features on top of it. Circle did the interpreted, compile-time pass idea before any of the other new systems languages. Carbon and C++Next both seem very directly "inspired" by Circle, but neither of those efforts seem to have actually produced anything yet. Ideally, Circle it would be open source. But I underst…

> Circle did the interpreted, compile-time pass idea before any of the other new systems languages. constexpr is in C++11, Jai is from 2014, and Zig 0.1.1 is from 2017. This project looks quite cool though.

With the small difference that Circle can use the complete language at compile time, constexpr is still far from it, and also gave birth to constinit and consteval.

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#15

Post by hobo_mark »

carabiner wrote: post #12
rogerclark wrote: post #3

Truly an amazing project. One person implementing the entire C++ standard, and then countless new, useful features on top of it. Circle did the interpreted, compile-time pass idea before any of the other new systems languages. Carbon and C++Next both seem very directly "inspired" by Circle, but neither of those efforts seem to have actually produced anything yet. Ideally, Circle it would be open source. But I underst…

He seems like a wonderboy. His linkedin has a recommendation: "Cannot say enough good things about this guy--probably the most capable programmer I've ever met."

Absolutely, also Sean made enough money in his previous life to be able to work on Circle full-time (while living in NYC), truly living the dream.

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#16

Post by Yoric »

erik_seaberg wrote: post #5
pjmlp wrote: post #4

From all possible wannabe be replacements for C++ that poped up in 2022, Circle is definitely the one that has the most going for it. Everything else requires rewriting everything, and they can only support a limited subset of C++ features, so if the goal is full compatibility with existing code they aren't going to achieve it anyway. For full rewrites, we already have enough alternatives with more maturity years beh…

This lays groundwork for opt-in safety per file, but safety should affect API design. Once you get done doing this to every file and refactoring every public API, have you really spent less effort than would have gone into a rewrite? If you only get halfway there, is the new version going to blow up any less often?

I agree that safety should affect API design, which means that there is at least one major piece missing after the rewrite. Either the ability to switch to an even stricter type system (e.g. Rust) or a ~zero cost binding generator to a stricter language (again, e.g. Rust).

However, before reaching that point, piecewise refactoring is something of considerable value. There are huge C++ codebases lying around that I believe would benefit immensely from a rewrite in a safer language, even if it's not as safe as Rust (or Scala, or F#, etc.)

Firefox and Chromium have already paid the entry price for piecewise refactoring into Rust, so they're probably not the best candidates. But there are many other examples that undoubtedly are, e.g. LLVM.

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#17

Post by charcircuit »

>simpler by disabling features that contribute to complexity, like multiple inheritance and function overloading.

Seeing function overloading show up surprises me. The only thing I can think of is having different semantics between different overloads, but removing overloads doesn't remove the issue. You just now have a poorly named function that isn't an overload.

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#18

Post by mjburgess »

Yoric wrote: post #16
erik_seaberg wrote: post #5

Earlier quoted context omitted.

This lays groundwork for opt-in safety per file, but safety should affect API design. Once you get done doing this to every file and refactoring every public API, have you really spent less effort than would have gone into a rewrite? If you only get halfway there, is the new version going to blow up any less often?

I agree that safety should affect API design, which means that there is at least one major piece missing after the rewrite. Either the ability to switch to an even stricter type system (e.g. Rust) or a ~zero cost binding generator to a stricter language (again, e.g. Rust). However, before reaching that point, piecewise refactoring is something of considerable value. There are huge C++ codebases lying around that I be…

Scala and F# are safer than Rust since they're on a VM.

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#19

Post by DrBazza »

pjmlp wrote: post #4

From all possible wannabe be replacements for C++ that poped up in 2022, Circle is definitely the one that has the most going for it. Everything else requires rewriting everything, and they can only support a limited subset of C++ features, so if the goal is full compatibility with existing code they aren't going to achieve it anyway. For full rewrites, we already have enough alternatives with more maturity years beh…

I hope circle is the thing that makes the committee realise there is an alternative to their attitude of 'we're not versioning files, we're not giving you opt-in features, we're not giving you new keywords, we're not fixing demonstrably bad and wrong behavior'. But I doubt it. I've been in and out of C++ for over 20 years, and every time I'm 'back', it's the same old tired story.

I'm more interested in Val than the rest, but, Val isn't really a C++ replacement (in terms of syntax, at least), it's a language that offers C++ interop. To quote an old joke 'How do you get to Dublin? Well, firstly, I wouldn't start here'. I'm not sure whether any new language in 2023 should start with C++ interop as one of its main goals.

Re: The first new build of Circle, a new C++20 compiler, since April 2022 is online

#20

Post by vadiml »

anonymoushn wrote: post #7
rogerclark wrote: post #3

Truly an amazing project. One person implementing the entire C++ standard, and then countless new, useful features on top of it. Circle did the interpreted, compile-time pass idea before any of the other new systems languages. Carbon and C++Next both seem very directly "inspired" by Circle, but neither of those efforts seem to have actually produced anything yet. Ideally, Circle it would be open source. But I underst…

> Circle did the interpreted, compile-time pass idea before any of the other new systems languages. constexpr is in C++11, Jai is from 2014, and Zig 0.1.1 is from 2017. This project looks quite cool though.

I think the first take on the subject was IBM with their PL/I Checkout and Optimizing compilers. They've integrated almost full PL/I language interpreter in the macro pre-processor stage. I was using it in the beginning of 80ies.
Post reply on HN