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

61–70 of 80 posts

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

#61

Post by seanbax »

gpderetta wrote: post #33
FpUser wrote: post #29

First the acknowledgement: to produce this amount of work single handedly - the guy is undisputed genius. do not want to go through the whole article but have this question: fn ParseAsInt() The goal for this new languages like Rust, Carbon, Go etc. is to introduce "better" alternatives to C and C++ languages and move the developers over. Nothing is wrong with that. Now to syntax: I completely understand syntax constr…

I think the author is simply showing that Circle can implement Carbon syntax using its metaprogramming capabilities on top of C++. It is not making a statement that the syntax itself is desirable.

That's right. I'm fine with normal C++ syntax. But other people have other opinions. And there is an allure of getting to a CFG so that non-compiler tooling could build a parse tree and do useful transformations. That's a good a goal.

I'm basically looking to evolve on multiple fronts at once. If there's an interest in new syntax, put resources. If there's interest in a borrow checker (I'm sure there is), put resources there. Just move up the field however you can.

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

#62

Post by seanbax »

tialaramex wrote: post #57
int_19h wrote: post #56

Earlier quoted context omitted.

Function overloading is orthogonal to the ability to define additional methods on existing types. C# has both, for example. Overloading is a don't-repeat-yourself thing - if you have a bunch of functions that do fundamentally the same thing with different types, encoding those types in the function name when they're already explicit in the arguments is simply redundant. Then there's an issue with ABI stability. Addin…

> if you have a bunch of functions that do fundamentally the same thing with different types That's where you should use parametric polymorphism, that's my point. C++ 23 defines _3_ overloads of string.contains() with parameter defined as variously a char, a char * and a string view, enabling name.contains("Jim") name.contains("Steve"sv) and name.contains('Q'). But if you need a fourth, too bad. Rust doesn't have ove…

Yes, interfaces open that up, and to a lesser extent choice types open that up. If your choice type supports all the alternatives from the original overload set, then you can reduce to one function.

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

#63

Post by zturner »

tialaramex wrote: post #52
DrBazza wrote: post #19

Earlier quoted context omitted.

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 r…

> we're not giving you new keywords Since when? Last time I looked C++ had almost a hundred keywords. C++ 20 added a bunch including "requires" and "concept" - both ordinary English words which oops, too bad now your software is incompatible because it used the wrong identifier.

It’s extremely difficult to get new keywords into the language. This is a very large part of the reason we can only have new functionality in the library.

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

#64

Post by 112233 »

DrBazza wrote: post #19
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 r…

It does look highly doubtful. On the one hand, there are things like 10'000 and 1_blah notation that obvoiusly breaks backwards everything, plus completely novel mini languages, like the stuff inside lambda []. On the two hand, there is the overpowering insistence on the c++ abstract machine with its lifetimes that has resulted in monsters like bit_cast, and has no resemblance to actual hardware, living or deceased. So the feeling is more of an ideology driven developement than any practical considerations

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

#65

Post by Yoric »

mjburgess wrote: post #58
tialaramex wrote: post #51

Earlier quoted context omitted.

The same "by construction" safety applies to Safe Rust as to the dynamic GC'd languages you're discussing. You can't write a use-after-free error in Safe Rust, the same way you can't write one in Javascript. But, Safe Rust also chooses to construct safety that those GC'd languages don't have. The reason Javascript doesn't have data races for example is that it doesn't have concurrency - can't have a race with only on…

You are right that the argument boils down to what we take "by construction" to mean. I will resolve this, simply, by saying whatever advertisement Rust makes for itself, is better made by any "dynamic" language. And if we're inclined to trade PR against PR, Rust looses. Managed memory has better PR. And so those repeating the Rust agitprop against managed languages are simply "NPCs for the wrong ideology".

I would articulate things differently.

Theoretically, memory-safety between Rust and managed languages is equivalent.

However, memory-safe languages (i.e. not Managed C++) running on a memory-safe VM have one more layer of defense in depth than Rust. This matters in case there is a bug in the compiler or any of the dependencies. Additional layers may include, for instance, Unix and containers.

"dynamic" languages, though? That's entirely orthogonal to memory-safety and not very good for general software safety.

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

#66

Post by int_19h »

FpUser wrote: post #59
int_19h wrote: post #55

Earlier quoted context omitted.

Tools are themselves "users" of syntax, and if you design a language without regard for their convenience at all, you end up in situations where e.g. code completion doesn't work because the syntax forces a forward reference (think of stuff like SELECT .. FROM ..), performance issues etc. And to the end users, the convenience should be considered as an aggregate metric: it's not just about writing code, but also abou…

>"That alone is, to me, sufficient reason to believe that changing it to Pascal-style "name: type" declarations, which are unambiguous, benefits both tools and humans, even if it's slightly more verbose." I am not against it. It is a different language altogether though. We were talking about "fixing" C++ while it is still being C++.

As it happens, C++ has already adopted "auto f() -> T" function declaration syntax many years ago in addition to "T f()", so this is arguably just a more streamlined take on that. I don't see how it makes it less C++, since conceptually everything is the same.

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

#67

Post by FpUser »

int_19h wrote: post #66
FpUser wrote: post #59

Earlier quoted context omitted.

>"That alone is, to me, sufficient reason to believe that changing it to Pascal-style "name: type" declarations, which are unambiguous, benefits both tools and humans, even if it's slightly more verbose." I am not against it. It is a different language altogether though. We were talking about "fixing" C++ while it is still being C++.

As it happens, C++ has already adopted "auto f() -> T" function declaration syntax many years ago in addition to "T f()", so this is arguably just a more streamlined take on that. I don't see how it makes it less C++, since conceptually everything is the same.

I shall admit my defeat ;)

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

#68

Post by GPMueller »

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…

Don’t forget about cpp2/cppfront — Herb Sutter has been in direct contact with Sean and it seems their discussions have had some impact on both their projects.

cpp2 is currently my favorite contender in this arena

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

#69

Post by gpderetta »

tialaramex wrote: post #57
int_19h wrote: post #56

Earlier quoted context omitted.

Function overloading is orthogonal to the ability to define additional methods on existing types. C# has both, for example. Overloading is a don't-repeat-yourself thing - if you have a bunch of functions that do fundamentally the same thing with different types, encoding those types in the function name when they're already explicit in the arguments is simply redundant. Then there's an issue with ABI stability. Addin…

> if you have a bunch of functions that do fundamentally the same thing with different types That's where you should use parametric polymorphism, that's my point. C++ 23 defines _3_ overloads of string.contains() with parameter defined as variously a char, a char * and a string view, enabling name.contains("Jim") name.contains("Steve"sv) and name.contains('Q'). But if you need a fourth, too bad. Rust doesn't have ove…

Just to be precise, traits and overloading are a form ad-hoc polymorphism not parametric.

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

#70

Post by fidgewidge »

seanbax wrote: post #60
fidgewidge wrote: post #21

Earlier quoted context omitted.

Yes, but so? When they can implement a feature in a forwards compatible way they do, when they can't, they don't and it's caveated as such. That's why nullable types and other Kotlin specific type stuff are encoded using annotations. It's the same strategy here. Carbon is (was?) also intended to compile to the C++ ABI and so does Circle, that's why it says it doesn't run on Windows (commercially a huge error. many of…

I'd like to target Windows. Windows does impose a specific C++ ABI, but it's completely undocumented. It's really just whatever Visual C++ does. C++ ABI is very complex, especially vtable layout and RTTI and EH. I am looking to get Microsoft's assistance on targeting Windows. It's a priority, but they don't want to help yet.

Isn't that what com is for? Win32 is compiler agnostic.
Post reply on HN