6 ms·

Sean Baxter: Safe C++ [video]

46 points by awesomekling 2y ago

pjmlp 2y ago
Circle is the real Typescript for C++, still hopeful some of this stuff helps to steer C++ into the right direction. Too much infrastructure code and industry standards, that will be kept being done in C++ for decades to come, and need a way for improving the whole security story.
rogerclark 2y ago
Someone please acquihire Sean and his compiler! This guy is a once-in-a-generation polymath: an expert in compilers (obviously), GPUs (worked on CUDA at NVIDIA), physics and topography (JPL etc). Buy the compiler, get somebody who could build you a nuclear reactor, drug discovery simulator and a GPU architecture. Deal of the century.
- germandiago 2y ago
  He is out of the ordinary for sure and a very smart person. But I still think that taking a more Hylo-like path to safety would be nicer and would complicate things less. FWIW, with Hylo you would rely on value semantics, you would not need Rust-style full-blown borrow checks with viral annotations, which is what he has been implementing and you would get rid of any kind of view types for parameter passing. You would just pass values. I really think that is the path forward to bet on. For whoever thinks Hylo is too new or experimental, it is not the language itself what is important but what C++ can learn from it. Hylo is based in experience implementing Swift by Dave Abrahams, Generic programming from Alex Stepanov and value semantics and structural polymorphism and value semantics and related work from Sean Parent. So even if the implementation itself is not so advanced, it is just a natural evolution of all things I just named here which have a track record of like 30 years at least in total with a lot of generic code and value semantics lessons and runtime polynorphism lessons learned.
  - pjmlp 2y ago
    Maybe we could eventually get -fsafe, I guess dreaming is allowed.
coffeeaddict1 2y ago
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.
PaulDavisThe1st 2y ago
It amazes me and makes me feel slightly more stupid to discover how much more easily I grok all this Rust stuff when it's expressed (elegantly) in what is basically C++.
- seanbax 2y ago
  Presenting a familiar syntax certainly makes it easier to follow.
- intelVISA 2y ago
  Rust is a solid lang but wider adoption will always be kneecapped by its syntax imo.
  - SubjectToChange 2y ago
    Syntax is mostly a function of familiarity. People coming to C++ from Rust or other languages often say the same thing.

46 points by awesomekling 2y ago

Circle is the real Typescript for C++, still hopeful some of this stuff helps to steer C++ into the right direction. Too much infrastructure code and industry standards, that will be kept being done in C++ for decades to come, and need a way for improving the whole security story.

rogerclark 2y ago

Someone please acquihire Sean and his compiler! This guy is a once-in-a-generation polymath: an expert in compilers (obviously), GPUs (worked on CUDA at NVIDIA), physics and topography (JPL etc). Buy the compiler, get somebody who could build you a nuclear reactor, drug discovery simulator and a GPU architecture. Deal of the century.

germandiago 2y ago
He is out of the ordinary for sure and a very smart person. But I still think that taking a more Hylo-like path to safety would be nicer and would complicate things less. FWIW, with Hylo you would rely on value semantics, you would not need Rust-style full-blown borrow checks with viral annotations, which is what he has been implementing and you would get rid of any kind of view types for parameter passing. You would just pass values. I really think that is the path forward to bet on. For whoever thinks Hylo is too new or experimental, it is not the language itself what is important but what C++ can learn from it. Hylo is based in experience implementing Swift by Dave Abrahams, Generic programming from Alex Stepanov and value semantics and structural polymorphism and value semantics and related work from Sean Parent. So even if the implementation itself is not so advanced, it is just a natural evolution of all things I just named here which have a track record of like 30 years at least in total with a lot of generic code and value semantics lessons and runtime polynorphism lessons learned.
- pjmlp 2y ago
  Maybe we could eventually get -fsafe, I guess dreaming is allowed.

coffeeaddict1 2y ago

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.

PaulDavisThe1st 2y ago

It amazes me and makes me feel slightly more stupid to discover how much more easily I grok all this Rust stuff when it's expressed (elegantly) in what is basically C++.

seanbax 2y ago
Presenting a familiar syntax certainly makes it easier to follow.
intelVISA 2y ago
Rust is a solid lang but wider adoption will always be kneecapped by its syntax imo.
- SubjectToChange 2y ago
  Syntax is mostly a function of familiarity. People coming to C++ from Rust or other languages often say the same thing.