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

51–60 of 80 posts

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

#51

Post by tialaramex »

mjburgess wrote: post #48
tialaramex wrote: post #46

Earlier quoted context omitted.

It seems weird to treat stuff that Scala must rely on but you can't write in Scala as part of the implementation, and yet not do the same for stuff Safe Rust has to rely on from Unsafe Rust.

Breaking down the full argument is very subtle, sure. But, at the outset, we can simply observe that the "safety" Rust provides is memory safety, which is a non-issue in a dynamic language. To say that Rust is as safe, or more safe, than a dynamic lang is false. It's strictly less safe, since by construction, it is a language where allocation is managed by the programmer. The whole argument about "saftey" in the sens…

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 one runner. Java does have data races (with limited but still unsettling consequences), Go's data races are really bad, like actual Undefined Behaviour bad in some cases. Whereas Safe Rust doesn't have data races - you can write concurrent Safe Rust but you can't write a data race.

The difference you're grappling for probably feels intuitively like it should exist, but I assure you it does not.

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

#52

Post by tialaramex »

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…

> 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.

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

#53

Post by steveklabnik »

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.

I suspect they're talking about co_*

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

#54

Post by int_19h »

mjburgess wrote: post #42
thesuperbigfrog wrote: post #38

Earlier quoted context omitted.

>> Scala and F# are safer than Rust since they're on a VM. Do you have any evidence to back up your claim? Both the JVM (Scala's VM) and the CLR (F#'s VM) have a history of vulnerabilities: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java+hotspo... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dotnet+clr Programming languages running on VM is not a safety guarantee.

In the relevant sense of safety, they are safer. The commenter's claim was not about vulnerabilities, since those apply to implementations, not to languages . The semantics of F#/Scala are memory safe because they're defined to be dynamic. The semantics of Rust are not memory safe. A subset of Rust is provably memory safe, but none that uses eg. much of the standard library which is unprovably memory safe against the…

Given that F# has unmanaged pointers (nativeptr), wouldn't it also be true that only a subset of it is provably memory safe, just like Rust?

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

#55

Post by int_19h »

FpUser wrote: post #32
tdiff wrote: post #30

Earlier quoted context omitted.

Guess it simplifies parsing, e.g. infamous "most vexing parse" etc.

Convenience should be for users of a tool not creator. And if it is fn than why not function instead. This single / double character constructs / modifiers in my opinion reduce readability. When reading Rust code apostrophe modifier for example is hard to see.

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 about reading code, compiling code, debugging code etc. You have to optimize for UX across the board, which sometimes necessitates compromises in some of those areas.

And the declaration syntax for C++ is so bad that, in the most general case, you can't even reliably tell if it's a declaration or not without knowing the compiler that'll process it! Consider:

   template struct a {
       template struct b {};
   };

   template struct a {
       enum { b };
   };

   enum { c, d };

   struct test : a {
       friend int main() {
           bd; // declaration or expression?
           &d;    // error or ok?
       }
   };
The first commented line above parses either as:

   b d; // local variable
or as:

   ((b  d); // expression
depending on whether sizeof(int)==sizeof(void*) on that particular implementation. Consequently, the following &d is either legal or not, depending on whether it's trying to take the address of a local or of an enum constant.

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.

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

#56

Post by int_19h »

tialaramex wrote: post #43
charcircuit wrote: post #17

>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.

If what you meant was actually a polymorphic function, just write the polymorphic function. If that's not what you meant then stop using the same name. I think the contrast between string contains in Rust and C++ is illustrative. Overloading means you only get whatever parameter types the stdlib provides in C++.

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. Adding a new function argument breaks any existing compiled code even if there is a default value, but adding a new overload and redirecting the old one to call the new one with the defaults is fine.

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

#57

Post by tialaramex »

int_19h wrote: post #56
tialaramex wrote: post #43

Earlier quoted context omitted.

If what you meant was actually a polymorphic function, just write the polymorphic function. If that's not what you meant then stop using the same name. I think the contrast between string contains in Rust and C++ is illustrative. Overloading means you only get whatever parameter types the stdlib provides in C++.

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 overloading, so it defines string.contains() as polymorphic over the parameter type Pattern, which enables name.contains("Jim") name.contains('J') name.contains(char::is_uppercase) name.contains(['B', 'o', 'b']) name.contains(|c| { my_fun(c, 206, local_var) }) and so on and so forth.

One reason C++ doesn't do this is addressed in Circle, by offering "interfaces" which are approximately equivalent to Rust's traits or the C++ 0x Concepts (as Sean firmly points out, these were very different than Stroustrup's C++ 20 Concepts)

The problem is, what does 'Q' have in common with "Jim" ? In conventional C++ polymorphism we want a base class and of course these are basic types, they don't have a base class, much less one which has the necessary commonality.

With interfaces, we can say what we care about isn't some hypothetical "base class" of string_view and char, but instead a common interface they both have dedicated to string matching, and now we're writing polymorphic software again.

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

#58

Post by mjburgess »

tialaramex wrote: post #51
mjburgess wrote: post #48

Earlier quoted context omitted.

Breaking down the full argument is very subtle, sure. But, at the outset, we can simply observe that the "safety" Rust provides is memory safety, which is a non-issue in a dynamic language. To say that Rust is as safe, or more safe, than a dynamic lang is false. It's strictly less safe, since by construction, it is a language where allocation is managed by the programmer. The whole argument about "saftey" in the sens…

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".

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

#59

Post by FpUser »

int_19h wrote: post #55
FpUser wrote: post #32

Earlier quoted context omitted.

Convenience should be for users of a tool not creator. And if it is fn than why not function instead. This single / double character constructs / modifiers in my opinion reduce readability. When reading Rust code apostrophe modifier for example is hard to see.

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++.

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

#60

Post by seanbax »

fidgewidge wrote: post #21
pjmlp wrote: post #13

Earlier quoted context omitted.

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.

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.
Post reply on HN