4 ms·

What this guy has achieved with Circle is nothing short of incredible! Writing an entirely new compiler (even if it's "just" a front-end to LLVM) and giving a c

What this guy has achieved with Circle is nothing short of incredible! Writing an entirely new compiler (even if it's "just" a front-end to LLVM) and giving a concrete demonstration of a borrow checker for a beast of a language like C++ is crazy (considering that he received zero help from anyone but himself). However, I'm afraid that the ISO C++ group is not ready for his proposal. We're talking about a committee which has stubbornly and consistently shown that they are willing to sacrifice safety and ergonomics in the name of backward compatibility. The introduction of a borrow checker is a huge change that will get shut down because someone somewhere is unwilling to rewrite their (often broken) code and/or compile their binaries again.

Maxatar 2y ago
The ISO committee is becoming increasingly less relevant. It's ineffectiveness has pushed numerous groups to create a successor to C++. It's no doubt a lot of work but if any of the successors to C++ such as Carbon, Circle, or cpp2 manage to release a solid compiler that is mostly compatible with C++17, I think you'll see a large migration towards it.
- gumby 2y ago
  I can't really evaluate your comment on relevance -- some things do seem to inexplicably bog down, but on others they move usefully and quickly. And the conservatism of compatibility really is incredibly important, which I say as someone who'd be happy (and relieved!) to blow away API compatibility (actually to use the API step capabilities already available behind the scenes, at least for ELF). But the part about "numerous groups to create a successor" doesn't really make your case: one of the best ways for things to get into any standard is to have multiple efforts that can be used as experience and starting points for the evolution of a standard. This has already happened a lot in the history of C++
- SubjectToChange 2y ago
  The ISO committee is becoming increasingly less relevant. It's ineffectiveness has pushed numerous groups to create a successor to C++. Maybe it is becoming less relevant, but language proposals and attendance has grown tremendously since 2010, with no signs of slowing down. The real issue is that it's functionally impossible for a single group to meet the needs of the entire community. It's no doubt a lot of work but if any of the successors to C++ such as Carbon, Circle, or cpp2 manage to release a solid compiler that is mostly compatible with C++17, I think you'll see a large migration towards it. Only time will tell, however I would bet against C++ successors. In particular, C++ is fundamentally hostile to cross-language interopt, to the degree that even C++ compilers struggle to maintain compatibility between themselves. For a language to work with C++, its compiler basically needs to contain a C++ compiler as well (as Carbon does). Moreover, simply being "compatible with C++17" is only the very first step to practical usage, e.g. consider how much work the Clang developers put into reverse engineering GCCisms. And that is before considering more exotic language extensions and APIs like OpenMP (and perhaps SYCL at some point as well). All the while C++ continues to change and evolve.
  - pjmlp 2y ago
    Which is exactly the reason. Now we have 300+ people voting on features that are never tested on a real compiler, before being set in stone. Compilers now are in different states of ISO C++ compliance, between ISO C++14 and ISO C++23. Several of those on paper features, deemed not quite right when implemented, and had to be redone between revisions, but naturally old ones kind of stay in, backwards compatibility. All languages are hostile to cross language interop, that is why everyone pretends to be C, or uses OS IPC.
    - SubjectToChange 2y ago
      Now we have 300+ people voting on features that are never tested on a real compiler, before being set in stone. Would you prefer that only 30 people should be allowed to hold up the acceptance of half-baked proposals? How could lower participation in C++ language evolution and/or standardization possibly do anything to improve the rigor and field testing of proposals? Compilers now are in different states of ISO C++ compliance, between ISO C++14 and ISO C++23. And? MSVC didn’t even do two-phase name lookup correctly until 2017, a fundamental feature of C++, yet the non-conforming behavior was little more than a nuisance. It’s really no concern of mine that Clang/libc++ hasn’t completed pstl support for C++17 because I wouldn’t be using it anyway. It is concerning when implementations half-asses a feature to pencil whip their “compliance” with new C++ standards (particularly when it only takes one implementation to make a feature useless for portable code). Several of those on paper features, deemed not quite right when implemented, and had to be redone between revisions, but naturally old ones kind of stay in, backwards compatibility. The developers behind major C++ implementations are acutely aware of every wart and failure, more so than virtually any end user. If they could they would choose to test every proposal on multiple compilers, across thousands of projects, targeting as many platforms as possible. But the resources and expertise to do so simply aren’t there. At some point the committee must hope for the best, take a leap of faith, and commit to a decision. It’s admirable that the C++ committee chooses to prioritize the needs of end users over the interests of implementations. All languages are hostile to cross language interop,… Managed languages do it every day (Kotlin and Java). But yes, the situation is quite different for native languages. What’s different about C++ is that it’s a remarkably difficult language to wrangle. C bindings are almost trivial to write or generate, but C++ introduces a mountain of complexity and ambiguity. There are dozens of projects which have incrementally rewritten C in Rust. But it’s practically impossible to do anything similar with C++. …that is why everyone pretends to be C, or uses OS IPC. No language wants to bear the cross of a stable ABI, much less an ossified ABI. A platform’s C implementation has already paid the price, everyone is welcome to freeload. That said, nothing good is ever free and the poverty of C ABIs prove it. With hardly any exceptions, describing a type C ABI as “fragile” is an understatement at best.

Maxatar 2y ago

The ISO committee is becoming increasingly less relevant. It's ineffectiveness has pushed numerous groups to create a successor to C++. It's no doubt a lot of work but if any of the successors to C++ such as Carbon, Circle, or cpp2 manage to release a solid compiler that is mostly compatible with C++17, I think you'll see a large migration towards it.

gumby 2y ago
I can't really evaluate your comment on relevance -- some things do seem to inexplicably bog down, but on others they move usefully and quickly. And the conservatism of compatibility really is incredibly important, which I say as someone who'd be happy (and relieved!) to blow away API compatibility (actually to use the API step capabilities already available behind the scenes, at least for ELF). But the part about "numerous groups to create a successor" doesn't really make your case: one of the best ways for things to get into any standard is to have multiple efforts that can be used as experience and starting points for the evolution of a standard. This has already happened a lot in the history of C++
SubjectToChange 2y ago
The ISO committee is becoming increasingly less relevant. It's ineffectiveness has pushed numerous groups to create a successor to C++. Maybe it is becoming less relevant, but language proposals and attendance has grown tremendously since 2010, with no signs of slowing down. The real issue is that it's functionally impossible for a single group to meet the needs of the entire community. It's no doubt a lot of work but if any of the successors to C++ such as Carbon, Circle, or cpp2 manage to release a solid compiler that is mostly compatible with C++17, I think you'll see a large migration towards it. Only time will tell, however I would bet against C++ successors. In particular, C++ is fundamentally hostile to cross-language interopt, to the degree that even C++ compilers struggle to maintain compatibility between themselves. For a language to work with C++, its compiler basically needs to contain a C++ compiler as well (as Carbon does). Moreover, simply being "compatible with C++17" is only the very first step to practical usage, e.g. consider how much work the Clang developers put into reverse engineering GCCisms. And that is before considering more exotic language extensions and APIs like OpenMP (and perhaps SYCL at some point as well). All the while C++ continues to change and evolve.
- pjmlp 2y ago
  Which is exactly the reason. Now we have 300+ people voting on features that are never tested on a real compiler, before being set in stone. Compilers now are in different states of ISO C++ compliance, between ISO C++14 and ISO C++23. Several of those on paper features, deemed not quite right when implemented, and had to be redone between revisions, but naturally old ones kind of stay in, backwards compatibility. All languages are hostile to cross language interop, that is why everyone pretends to be C, or uses OS IPC.
  - SubjectToChange 2y ago
    Now we have 300+ people voting on features that are never tested on a real compiler, before being set in stone. Would you prefer that only 30 people should be allowed to hold up the acceptance of half-baked proposals? How could lower participation in C++ language evolution and/or standardization possibly do anything to improve the rigor and field testing of proposals? Compilers now are in different states of ISO C++ compliance, between ISO C++14 and ISO C++23. And? MSVC didn’t even do two-phase name lookup correctly until 2017, a fundamental feature of C++, yet the non-conforming behavior was little more than a nuisance. It’s really no concern of mine that Clang/libc++ hasn’t completed pstl support for C++17 because I wouldn’t be using it anyway. It is concerning when implementations half-asses a feature to pencil whip their “compliance” with new C++ standards (particularly when it only takes one implementation to make a feature useless for portable code). Several of those on paper features, deemed not quite right when implemented, and had to be redone between revisions, but naturally old ones kind of stay in, backwards compatibility. The developers behind major C++ implementations are acutely aware of every wart and failure, more so than virtually any end user. If they could they would choose to test every proposal on multiple compilers, across thousands of projects, targeting as many platforms as possible. But the resources and expertise to do so simply aren’t there. At some point the committee must hope for the best, take a leap of faith, and commit to a decision. It’s admirable that the C++ committee chooses to prioritize the needs of end users over the interests of implementations. All languages are hostile to cross language interop,… Managed languages do it every day (Kotlin and Java). But yes, the situation is quite different for native languages. What’s different about C++ is that it’s a remarkably difficult language to wrangle. C bindings are almost trivial to write or generate, but C++ introduces a mountain of complexity and ambiguity. There are dozens of projects which have incrementally rewritten C in Rust. But it’s practically impossible to do anything similar with C++. …that is why everyone pretends to be C, or uses OS IPC. No language wants to bear the cross of a stable ABI, much less an ossified ABI. A platform’s C implementation has already paid the price, everyone is welcome to freeload. That said, nothing good is ever free and the poverty of C ABIs prove it. With hardly any exceptions, describing a type C ABI as “fragile” is an understatement at best.