Absolutely. And all built by one (1) person. It's mind-boggling. Not to mention that the Circle compiler also features basically the Rust trait system, discriminated unions, pattern matching, and whatnot. One can bikeshed syntax or question some of the decisions in Circle all day long, but just to think what can be achieved by one determined individual. Not to denigrate the people working on the C++ standard (who are clearly much smarter than me), but contrasting all of this with C++20 concepts, which took a decade and delivered something worse than what was already prepared for C++11... it's just a little bit depressing. But I digress. Having this "Rustified C++" as presented here to fix critical parts of a codebase would of course be much preferable to adding a new language and dealing with interop.
No one else has anything remotely comparable as an effort to bring Rust-like memory and thread safety into C++ - this is the only game in town. And it's THE thing that C++ badly needs to remain a viable multi-domain and systems programming language going forward. What is needed is for gcc, clang, and Microsoft to implement what Sean has done in their respective compilers as an extension - doing so where all implementations adhere compatibly to a spec. This could foster a kind of momentum that could bring a steam roller of pressure onto the C++ standards committe to rubberstamp. So what is needed is a full-on conspiracy of the prominent C++ compiler teams to do this in unison. The tail should just wag the dog in this particular case so that C++ can have a way to maintain furure viability for even green field projects. Otherwise it will be relegated to the fate of COBOL and FORTRAN - only important for the sake of legacy code commitments.
Correction on Send/Sync: in Rust &mut T is Send if T is Send, and you can send a &mut T to a different thread. What prevents a data race caused by mutating the same object through that mutable reference is instead the borrow checker: the object is considered borrowed while the thread is running, so you cannot also use it from the thread that spawned the second one. Note that you'll have to use std::thread::scope to see this, since with std::thread::spawn it will still not satisfy the static bound.
56:20 Rust provides thread::scope() for spawning threads with a bounded lifetime, which allow borrowing non-static data. Circle's std2::thread could implement a similar api
This is some seriously impressive stuff.
Absolutely. And all built by one (1) person. It's mind-boggling. Not to mention that the Circle compiler also features basically the Rust trait system, discriminated unions, pattern matching, and whatnot.
One can bikeshed syntax or question some of the decisions in Circle all day long, but just to think what can be achieved by one determined individual. Not to denigrate the people working on the C++ standard (who are clearly much smarter than me), but contrasting all of this with C++20 concepts, which took a decade and delivered something worse than what was already prepared for C++11... it's just a little bit depressing.
But I digress. Having this "Rustified C++" as presented here to fix critical parts of a codebase would of course be much preferable to adding a new language and dealing with interop.
No one else has anything remotely comparable as an effort to bring Rust-like memory and thread safety into C++ - this is the only game in town. And it's THE thing that C++ badly needs to remain a viable multi-domain and systems programming language going forward.
What is needed is for gcc, clang, and Microsoft to implement what Sean has done in their respective compilers as an extension - doing so where all implementations adhere compatibly to a spec.
This could foster a kind of momentum that could bring a steam roller of pressure onto the C++ standards committe to rubberstamp.
So what is needed is a full-on conspiracy of the prominent C++ compiler teams to do this in unison. The tail should just wag the dog in this particular case so that C++ can have a way to maintain furure viability for even green field projects. Otherwise it will be relegated to the fate of COBOL and FORTRAN - only important for the sake of legacy code commitments.
Correction on Send/Sync: in Rust &mut T is Send if T is Send, and you can send a &mut T to a different thread. What prevents a data race caused by mutating the same object through that mutable reference is instead the borrow checker: the object is considered borrowed while the thread is running, so you cannot also use it from the thread that spawned the second one. Note that you'll have to use std::thread::scope to see this, since with std::thread::spawn it will still not satisfy the static bound.
Thanks. Subtle point. My mistake.
56:20 Rust provides thread::scope() for spawning threads with a bounded lifetime, which allow borrowing non-static data. Circle's std2::thread could implement a similar api
I'd be curious to hear from the Rust community about any legacy aspects of the language they'd want to change before we try bringing it all into C++.
Great work. Thanks.
I wish I had what it takes to help bring this to MingW, MacOS, and Arm. aarch64 in particular would be useful.
Production ready when?
Is this already on godbolt?