4 ms·

Any successor to C++ will necessarily need to be built around safety from day one. Carbon did not do that - it merely hopes to put safety in at a later stage. S

Any successor to C++ will necessarily need to be built around safety from day one. Carbon did not do that - it merely hopes to put safety in at a later stage. So no, I don’t think Carbon will replace C++. I will be very surprised if a C++ successor will be a new language. I think it will be a frontend to C++ that cleans up the syntax, has much stricter rules around UB, and can rely on C++ as its unsafe counterpart. C++ itself will never be safe - it can’t be while maintaining backwards compatibility, and even modern features (ranges, coroutines) provide a wide range of new lifetime nightmares. A new frontend could solve a lot of that, while allowing unsafe “trust me bro” code to be written in C++. There’s the “enable new features in a file with pragmas” idea, too, which could be promising. But I’m not convinced.

fortran77 4y ago
Unsafe rust code is "trust me bro" too
- lpapez 4y ago
  Except it is not though. Unsafe blocks are "hey check this extra carefully because it might be unsafe" instead of everything being implicitly unsafe everywhere.
- i-use-nixos-btw 4y ago
  Exactly! And yet Rust gets a reputation of safety: the boundary between safe and unsafe is formal, and that opens up huge possibilities for metrics, compliance, and targeted testing. That’s what I’d shoot for.
  - armchairhacker 4y ago
    People say this a lot. But formal methods is really hard and really tedious. Especially if you can't write whatever you're trying to prove safe in safe rust, it's going to be even harder and more tedious. To give perspective: CompCert (a C compiler with formally-proven semantics, arguably one of the largest formally-proven programs to date) has been developed for decades and still does not support all C99 features; it and sel4 (a formally-verified safe microkernel) are both single-core because proving properties in complex multicore interactions has basically not been done (sel4 actually does have a multicore implementation, but it's not yet formally verified). Safety, performance, ease-of-use: pick two. If we really care about safety, the easiest solution for many is to just use a language like Java or Python where everything is boxed and checked and there is no truly unsafe code. Safe Rust strikes a really nice balance of being almost formally-proven safe, almost as performant as unsafe Rust/C++, and almost as easy to use as more general-purpose-languages (the extent of the third "almost" varies widely among developers).
coderjames 4y ago
> frontend to C++ that cleans up the syntax, has much stricter rules around UB, and can rely on C++ as its unsafe counterpart You're looking for Herb Sutter's CppFront: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront As Cfront was to C, Cppfront is to C++.
- i-use-nixos-btw 4y ago
  Syntactically, I find cppfront gorgeous. However, I’d like to have seen more emphasis on safety by design, rather than safety by excluding things. I think it’s definitely easier to get it in at this stage of cppfront’s development than it would be of Carbon, but that’s because the implementation is incredibly simple and the technical debt is low. I have high hopes for cppfront, though. I hope it grows into a full frontend rather than a preprocessing step.
rjh29 4y ago
It's very opinionated and SerenityOS-focused, but the language Jakt ( https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt ) transpiles to C++, has memory safety and some very neat ideas for readability.
- jeroenhd 4y ago
  I love the SerenityOS project, the subprojects, and the passionate people behind it, but I doubt Jakt is going to get any more serious use than most other toy languages. I think Jakt will be as much a production programming language as SerenityOS will be a production operating system. Interoperability with C++ is a very nice and useful thing but the language still needs work. Andreas' video on writing code that actually does stuff in Jakt made it clear that there are still places where the language needs to be improved (which is fine, it's not finished) and at its current state I think it'll be a while before the language gains any adoption. The language reminds me of Zig in a way, which also featured a "transpile a language into another" approach up until recently. Unlike Zig, Jakt actually seems to have usable syntax highlighting and IDE support beyond "highlight these specific keywords". I've never found any IDE that works well with Zig, and the people I asked told me to use an older, buggy highlighter and ignore the errors or program without any IDE support. Despite its immaturity, it's already nicer to just work with than the language behind Bun, a JS runtime mentioned here on HN a lot. That's very promising for the future of Jakt at the very least.
  - rjh29 4y ago
    Yeah, I neglected to mention that it's nowhere near finished, but it's under heavy development and the interoperability with C++ means there's a low barrier for adoption, so who knows?

fortran77 4y ago

Unsafe rust code is "trust me bro" too

lpapez 4y ago
Except it is not though. Unsafe blocks are "hey check this extra carefully because it might be unsafe" instead of everything being implicitly unsafe everywhere.
i-use-nixos-btw 4y ago
Exactly! And yet Rust gets a reputation of safety: the boundary between safe and unsafe is formal, and that opens up huge possibilities for metrics, compliance, and targeted testing. That’s what I’d shoot for.
- armchairhacker 4y ago
  People say this a lot. But formal methods is really hard and really tedious. Especially if you can't write whatever you're trying to prove safe in safe rust, it's going to be even harder and more tedious. To give perspective: CompCert (a C compiler with formally-proven semantics, arguably one of the largest formally-proven programs to date) has been developed for decades and still does not support all C99 features; it and sel4 (a formally-verified safe microkernel) are both single-core because proving properties in complex multicore interactions has basically not been done (sel4 actually does have a multicore implementation, but it's not yet formally verified). Safety, performance, ease-of-use: pick two. If we really care about safety, the easiest solution for many is to just use a language like Java or Python where everything is boxed and checked and there is no truly unsafe code. Safe Rust strikes a really nice balance of being almost formally-proven safe, almost as performant as unsafe Rust/C++, and almost as easy to use as more general-purpose-languages (the extent of the third "almost" varies widely among developers).

coderjames 4y ago

> frontend to C++ that cleans up the syntax, has much stricter rules around UB, and can rely on C++ as its unsafe counterpart You're looking for Herb Sutter's CppFront: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront As Cfront was to C, Cppfront is to C++.

i-use-nixos-btw 4y ago
Syntactically, I find cppfront gorgeous. However, I’d like to have seen more emphasis on safety by design, rather than safety by excluding things. I think it’s definitely easier to get it in at this stage of cppfront’s development than it would be of Carbon, but that’s because the implementation is incredibly simple and the technical debt is low. I have high hopes for cppfront, though. I hope it grows into a full frontend rather than a preprocessing step.

rjh29 4y ago

It's very opinionated and SerenityOS-focused, but the language Jakt ( https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt ) transpiles to C++, has memory safety and some very neat ideas for readability.

jeroenhd 4y ago
I love the SerenityOS project, the subprojects, and the passionate people behind it, but I doubt Jakt is going to get any more serious use than most other toy languages. I think Jakt will be as much a production programming language as SerenityOS will be a production operating system. Interoperability with C++ is a very nice and useful thing but the language still needs work. Andreas' video on writing code that actually does stuff in Jakt made it clear that there are still places where the language needs to be improved (which is fine, it's not finished) and at its current state I think it'll be a while before the language gains any adoption. The language reminds me of Zig in a way, which also featured a "transpile a language into another" approach up until recently. Unlike Zig, Jakt actually seems to have usable syntax highlighting and IDE support beyond "highlight these specific keywords". I've never found any IDE that works well with Zig, and the people I asked told me to use an older, buggy highlighter and ignore the errors or program without any IDE support. Despite its immaturity, it's already nicer to just work with than the language behind Bun, a JS runtime mentioned here on HN a lot. That's very promising for the future of Jakt at the very least.
- rjh29 4y ago
  Yeah, I neglected to mention that it's nowhere near finished, but it's under heavy development and the interoperability with C++ means there's a low barrier for adoption, so who knows?