4 ms·

Sean (the author of Circle) is an impressive guy. He started pursuing this work at about the same point several of the "C++ Successor Languages" were created, b

Sean (the author of Circle) is an impressive guy. He started pursuing this work at about the same point several of the "C++ Successor Languages" were created, but although all of them claimed to be about solving this problem, especially when first announced, they actually don't have a solution unlike this Circle work. Let me briefly enumerate: Val (now HyLo) says it wants to solve this problem... but it doesn't yet have the C++ interop stuff, so, it's just really a completely different language nobody uses. Carbon wants to ship a finished working Carbon language, then bolt on safety (somehow) but, only for some things, not data races for example, so, you still don't actually have Rust's Memory Safety Cpp2 explicitly says it isn't even interested in solving the problem, Herb says if he can produced measurements saying it's "safer" somehow that's good enough. It's interesting how many good ideas from Rust just come along free for the ride when you try to do this, do you like Destructive Move? Good news, that's how you make this work in Rust so that's how Circle does it. Exhaustive Pattern Matching? Again, Circles does that for the same reason Rust needs it. It is certainly true that this is not the Only Possible Way to get Safety. It would be profoundly weird if Rust had stumbled onto such a thing, but "Let's just copy the thing that worked in Rust" is somehow at once the simplest possible plan that could work and an astonishing achievement for one man.

Vt71fcAqt7 2y ago
>Carbon wants to ship a finished working Carbon language, then bolt on safety (somehow) but, only for some things, not data races for example, so, you still don't actually have Rust's Memory Safety I'm not sure this is correct. As I understand it, Carbon's plan is to add a borrow checker like Rust's. From a recent talk[0][1] by one of the lead developers: >Best candidate for C++ is likely similar to Rust’s borrow checker [0] slides: https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/index.html#/105 https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/in... [1] relevant timestamps: https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s
- tialaramex 2y ago
  Chandler has explicitly said that he doesn't see a reason to solve data races. The borrow checker isn't enough on its own to solve this in Rust, Sean explains (probably deeper in Circle's documentation) that you need to track a new property of types which is infectious, Rust does this with the Send and Sync traits.
  - Vt71fcAqt7 2y ago
    You're right. In fact it was in the previous slide[0] from that same talk. Thanks for pointing that out. [0] https://youtube.com/watch?v=1ZTJ9omXOQ0?t=1h8m19s https://youtube.com/watch?v=1ZTJ9omXOQ0?t=1h8m19s
  - chandlerc1024 2y ago
    "Chandler has explicitly said that he doesn't see a reason to solve data races." Er, the slide title says that solving this is highly desirable, just not a strict requirement for security purposes. Not sure how that's the same as "doesn't see a reason to solve data races". I see lots of reasons. I just think it is possible to achieve the security goals without it. FWIW, I'm hopeful we'll end up including this in whatever model we end up with for Safe Carbon. It's just a degree of freedom we also shouldn't ignore when designing it.
    - Vt71fcAqt7 2y ago
      Thanks for clarifying that point. It's worth pointing out that the safety strategy doc[0] mentions that >A key subset of safety categories Carbon should address are: >[...] >Data race safety protects against racing memory access: when a thread accesses (read or write) a memory location concurrently with a different writing thread and without synchronizing But then later in the doc it says >It's possible to modify the Rust model several ways in order to reduce the burden on C++ developers: >Don't offer safety guarantees for data races, eliminating RefCell. >[...] >Overall, Carbon is making a compromise around safety in order to give a path for C++ to evolve. [...] One could read this as saying that guaranteed safety against data races is not a goal. Perhaps this doc could be reworded? Maybe something like "Carbon does not see guaranteed safety against data races as strictly necessary to achieve its security goals but we still currently aim for a model that will prevent them." [0] https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/principles/safety_strategy.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...
pjmlp 2y ago
Right now, Circle looks like the only Typescript like evolution path for existing C++, with a production quality compiler. Unfortunately WG21 seems to have some issues with any ideas coming out from Circle, going back to its early days, and I don't see them being willing to adopt Sean's work. Which is really a pity, as he single handled managed to deliver more than whole C++ compiler folks, stuck in endless discussions about the philosophical meaning of the word safety. Maybe at least some vendor in high integrity computing domain does adopt his work.
- jokoon 2y ago
  > Unfortunately WG21 seems to have some issues with any ideas coming out from Circle, going back to its early days, and I don't see them being willing to adopt Sean's work. What reasons? Are those valid?
  - pjmlp 2y ago
    It was due to the metaprogramming capabilities, due to how Circle enables to use full C++ at compile time instead of constexpr/constinit/constval, David Sankel has a talk where he jokes with the WG21 decision process that was behind it, "Don't constexpr All the Things", from CppNow 2021, https://youtu.be/NNU6cbG96M4?t=2045 https://youtu.be/NNU6cbG96M4?t=2045
    - fweimer 2y ago
      Well, GCC supports -fimplicit-constexpr these days: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-fimplicit-constexpr https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Optio...
- triblemaster 2y ago
  from what I understand, there's a price Sean is asking for his work which no one is willing to pay at this moment.
wrsh07 2y ago
I'm very confused by the love for circle - there's a GitHub that hasn't been updated for 7 months that doesn't have a license. When I first heard about it, a lot of the ideas seemed interesting, but are there users of it? I think my biggest question is "what is the goal here?" For carbon they're pretty explicit that it's a research prototype. If anything is to come if it, it will need to be usable at Google's scale (they have real issues with build times, they build from head so abi compatibility isn't required, etc) Herb wasn't really designing cpp2 as a successor language so much as a playground to understand what features might make sense to propose for adoption in c++. What is circle? It's more than just some project, but the ideas haven't been adopted in cpp and the compiler repository isn't being updated
- steveklabnik 2y ago
  Circle is not open source, that’s correct.
  - dwheeler 2y ago
    I think that's automatically a dead end, then. People have inceasingly abandoned closed source compilers, they create a huge risk if the maker decides to stop maintaining it. Most languages that people pick up have an open source software implementation.
    - steveklabnik 2y ago
      I think it's more complicated than that, but I agree that it's a factor that would give some folks pause for currently adopting Circle.
    - jay-barronville 2y ago
      In most cases, I’d probably agree with your point here, but in this case, I think you’re wrong. If Circle can truly accomplish its stated goals, the value proposition of a memory-safe superset of C++ is ginormous. Lots of companies with critical software written in C++ won’t care that Circle isn’t open-source as long as it ticks all of their boxes (certifications, audits, etc.) and they have a strong enterprise support story. This isn’t your average project.

Vt71fcAqt7 2y ago

>Carbon wants to ship a finished working Carbon language, then bolt on safety (somehow) but, only for some things, not data races for example, so, you still don't actually have Rust's Memory Safety I'm not sure this is correct. As I understand it, Carbon's plan is to add a borrow checker like Rust's. From a recent talk[0][1] by one of the lead developers: >Best candidate for C++ is likely similar to Rust’s borrow checker [0] slides: https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/index.html#/105 https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/in... [1] relevant timestamps: https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s

tialaramex 2y ago
Chandler has explicitly said that he doesn't see a reason to solve data races. The borrow checker isn't enough on its own to solve this in Rust, Sean explains (probably deeper in Circle's documentation) that you need to track a new property of types which is infectious, Rust does this with the Send and Sync traits.
- Vt71fcAqt7 2y ago
  You're right. In fact it was in the previous slide[0] from that same talk. Thanks for pointing that out. [0] https://youtube.com/watch?v=1ZTJ9omXOQ0?t=1h8m19s https://youtube.com/watch?v=1ZTJ9omXOQ0?t=1h8m19s
- chandlerc1024 2y ago
  "Chandler has explicitly said that he doesn't see a reason to solve data races." Er, the slide title says that solving this is highly desirable, just not a strict requirement for security purposes. Not sure how that's the same as "doesn't see a reason to solve data races". I see lots of reasons. I just think it is possible to achieve the security goals without it. FWIW, I'm hopeful we'll end up including this in whatever model we end up with for Safe Carbon. It's just a degree of freedom we also shouldn't ignore when designing it.
  - Vt71fcAqt7 2y ago
    Thanks for clarifying that point. It's worth pointing out that the safety strategy doc[0] mentions that >A key subset of safety categories Carbon should address are: >[...] >Data race safety protects against racing memory access: when a thread accesses (read or write) a memory location concurrently with a different writing thread and without synchronizing But then later in the doc it says >It's possible to modify the Rust model several ways in order to reduce the burden on C++ developers: >Don't offer safety guarantees for data races, eliminating RefCell. >[...] >Overall, Carbon is making a compromise around safety in order to give a path for C++ to evolve. [...] One could read this as saying that guaranteed safety against data races is not a goal. Perhaps this doc could be reworded? Maybe something like "Carbon does not see guaranteed safety against data races as strictly necessary to achieve its security goals but we still currently aim for a model that will prevent them." [0] https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/principles/safety_strategy.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...

pjmlp 2y ago

Right now, Circle looks like the only Typescript like evolution path for existing C++, with a production quality compiler. Unfortunately WG21 seems to have some issues with any ideas coming out from Circle, going back to its early days, and I don't see them being willing to adopt Sean's work. Which is really a pity, as he single handled managed to deliver more than whole C++ compiler folks, stuck in endless discussions about the philosophical meaning of the word safety. Maybe at least some vendor in high integrity computing domain does adopt his work.

jokoon 2y ago
> Unfortunately WG21 seems to have some issues with any ideas coming out from Circle, going back to its early days, and I don't see them being willing to adopt Sean's work. What reasons? Are those valid?
- pjmlp 2y ago
  It was due to the metaprogramming capabilities, due to how Circle enables to use full C++ at compile time instead of constexpr/constinit/constval, David Sankel has a talk where he jokes with the WG21 decision process that was behind it, "Don't constexpr All the Things", from CppNow 2021, https://youtu.be/NNU6cbG96M4?t=2045 https://youtu.be/NNU6cbG96M4?t=2045
  - fweimer 2y ago
    Well, GCC supports -fimplicit-constexpr these days: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-fimplicit-constexpr https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Optio...
triblemaster 2y ago
from what I understand, there's a price Sean is asking for his work which no one is willing to pay at this moment.

wrsh07 2y ago

I'm very confused by the love for circle - there's a GitHub that hasn't been updated for 7 months that doesn't have a license. When I first heard about it, a lot of the ideas seemed interesting, but are there users of it? I think my biggest question is "what is the goal here?" For carbon they're pretty explicit that it's a research prototype. If anything is to come if it, it will need to be usable at Google's scale (they have real issues with build times, they build from head so abi compatibility isn't required, etc) Herb wasn't really designing cpp2 as a successor language so much as a playground to understand what features might make sense to propose for adoption in c++. What is circle? It's more than just some project, but the ideas haven't been adopted in cpp and the compiler repository isn't being updated

steveklabnik 2y ago
Circle is not open source, that’s correct.
- dwheeler 2y ago
  I think that's automatically a dead end, then. People have inceasingly abandoned closed source compilers, they create a huge risk if the maker decides to stop maintaining it. Most languages that people pick up have an open source software implementation.
  - steveklabnik 2y ago
    I think it's more complicated than that, but I agree that it's a factor that would give some folks pause for currently adopting Circle.
  - jay-barronville 2y ago
    In most cases, I’d probably agree with your point here, but in this case, I think you’re wrong. If Circle can truly accomplish its stated goals, the value proposition of a memory-safe superset of C++ is ginormous. Lots of companies with critical software written in C++ won’t care that Circle isn’t open-source as long as it ticks all of their boxes (certifications, audits, etc.) and they have a strong enterprise support story. This isn’t your average project.