3 ms·

If you've seen this before, it's worth looking at the 2025 roadmap – it's long-term work, a full safety story hasn't been quite figured out (TBD end 2025), and

If you've seen this before, it's worth looking at the 2025 roadmap – it's long-term work, a full safety story hasn't been quite figured out (TBD end 2025), and 0.1 is TBD end 2026. About the pace of Rust, although without the active forum that Rust had in its early days. https://docs.carbon-lang.dev/docs/project/roadmap.html https://docs.carbon-lang.dev/docs/project/roadmap.html What _is_ interesting is that I get the impression that Carbon is being workshopped with the C++ community, rather than the wider PLT community -- I worry that they won't benefit from the broader perspectives that'll help it avoid well-known warts elsewhere.

ryanobjc 1y ago
I think there are parallels with functional languages on the JVM. The parts that are the worst are the parts that were built for maximum interoperability. Not to mention that the JVM forces classes on you at the deepest opcode levels. Compatibility with C++ is fine, but so far it seems carbon's safety story is entirely a wishlist rather than anything yet. Seems like Carbon might be a more of a place to demonstrate features for C++ committees than a real language? Personally I have hand it up to here with lousy programmingn languages that make it easy for me to write bugs.
IshKebab 1y ago
> being workshopped with the C++ community Honestly seems like a dubious idea. The C++ community that remains are even more "just get good" than before. They still think UB all over the place is fine.
- bla3 1y ago
  I think that might be true of the language committee, but there's presumably a huge crowd of people with existing c++ code bases that would like to have a different path forward than just hoping that the committee changes priorities.
  - pjmlp 1y ago
    That is what many of us have done moving into managed languages, with native libraries when required to do so. The remaining people driving where the language goes have other priorities in mind like reflection. The profiles that were supposed to be so much better than the Safe C++ proposal, none of them made it into C++26, and it remains to be seen if we ever will see a sensible preview implementation for C++29.
    - tialaramex 1y ago
      C++ 26 doesn't have the technology, but it wouldn't matter anyway because what's crucial about Rust isn't the technology it's the culture. If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does. Beyond that though, the profiles idea is dead in the water because it doesn't deliver composition. Rust's safety composes. Jim's safe Activity crate, Sarah's safe Animals crate and Dave's safe Networking crate compose to let me work with a safe IPv6-capable juggling donkey even though Jim, Sarah and Save have never met and had no idea I would try that. A hypothetical C++ 29 type safe Activity module, combined with a thread safe Animals module, and a resource leak safe Networking module doesn't even get you something that will definitely work, let alone deliver any particular safety.
      - marsven_422 1y ago
        [dead]
      - pjmlp 1y ago
        Yeah, that sums it all quite nicely, see contracts proposal as a good example of that.
      - justcuriousab 1y ago
        > If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does. But Rust allows pattern matching on floats. https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a732d173c98ece1e58b3272015d1dae6 https://play.rust-lang.org/?version=stable&mode=debug&editio... Rust Zulip is C++ WG21 confirmed?
- GuB-42 1y ago
  I'd say the C++ community is torn. Some part of it want C++ to be Rust, with a focus on compile-time safety. Others take "C++" literally as "C with extra stuff" and value performance over safety. Companies like Google are likely to be in the former camp, as for what they are doing, security is critical. Unsurprisingly, Carbon is a Google project. Video game companies on the other hand are likely to be in the latter camp. Most of the times, security is not as critical, especially for offline games, and memory corruption usually don't go further than a game crash. Tight memory management however is critical, and it often involves raw pointers and custom allocation schemes.
  - JonChesterfield 1y ago
    I blame the "we won't recompile anything ever" stance from the financial organisations for the breakdown. It means C++ cannot fix mistakes, even when they harm performance, under the general name of "abi stability". Thus there is an opening for a faster language. And still for a safer one. And for an easier one to use. So all C++ has going for it is inertia. It's moribund unless the committee reconsider their stance on intentionally losing the performance competition.
    - Buttons840 1y ago
      Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages? A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust. There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common. (Maybe Rust could do this, but they haven't stabilized their ABI yet, and I don't the details.) [0]: https://faultlore.com/blah/c-isnt-a-language/ https://faultlore.com/blah/c-isnt-a-language/
      - Gibbon1 1y ago
        I remember reading that google tried to impress on WG21 and 14 the need to update the ABI and they were utterly opposed. The result is google is no longer interested in C++. Apple I think is also no longer interested in C++. I think also Swift now has a stable ABI.
wocram 1y ago
Carbon is just trying to bring a rust-like edition to cpp, there's no reason for non cpp users to Carbon.
pjmlp 1y ago
Main goal for Carbon is to port existing code first, general purpose second, with Google internal teams as main customer. If it ever goes beyond that remains to be seen. The Carbon team is the first to point out that anyone doing green field development should reach out to Rust or any managed language that fits the project scope.
chandlerc1024 1y ago
> What _is_ interesting is that I get the impression that Carbon is being workshopped with the C++ community, rather than the wider PLT community -- I worry that they won't benefit from the broader perspectives that'll help it avoid well-known warts elsewhere. FWIW, we're working hard whenever looking at an aspect of the language to look at other languages beyond C++ and learn any and everything we can from them. Lots of our design proposals cite Swift, Rust, Go, TypeScript, Python, Kotlin, C#, Java, and even Scala.
- steveklabnik 1y ago
  Make sure you're checking out Hylo. I'm not sure that its ideas are right for Carbon, but if you're looking for a credible alternative to Rust's take on safety, I think it's one of the better ones.
  - chandlerc1024 1y ago
    We've been watching closely since before the name change. =D Had lots of conversations with several of the folks involved.
- sour-taste 1y ago
  Chandler I would love to be involved in Carbon development to shape its development to be usable at my company or alternatively to use it in my own projects. What is the best way to stay involved in Carbon development? Just the discord?
  - chandlerc1024 1y ago
    In increasing order of volume of material: - Our newsletter / announcements via GitHub Discussions[1] email[2] or RSS[3] - The "Last Week in Carbon" posts via GitHub[4] or RSS[5] - The Discord server: https://discord.gg/ZjVdShJDAs https://discord.gg/ZjVdShJDAs [1]: https://github.com/carbon-language/carbon-lang/discussions/categories/announcements https://github.com/carbon-language/carbon-lang/discussions/c... [2]: https://groups.google.com/a/carbon-lang.dev/g/announce https://groups.google.com/a/carbon-lang.dev/g/announce [3]: https://github.com/carbon-language/carbon-lang/discussions/categories/announcements.atom https://github.com/carbon-language/carbon-lang/discussions/c... [4]: https://github.com/carbon-language/carbon-lang/discussions/categories/last-week-in-carbon https://github.com/carbon-language/carbon-lang/discussions/c... [5]: https://github.com/carbon-language/carbon-lang/discussions/categories/last-week-in-carbon.atom https://github.com/carbon-language/carbon-lang/discussions/c...

ryanobjc 1y ago

I think there are parallels with functional languages on the JVM. The parts that are the worst are the parts that were built for maximum interoperability. Not to mention that the JVM forces classes on you at the deepest opcode levels. Compatibility with C++ is fine, but so far it seems carbon's safety story is entirely a wishlist rather than anything yet. Seems like Carbon might be a more of a place to demonstrate features for C++ committees than a real language? Personally I have hand it up to here with lousy programmingn languages that make it easy for me to write bugs.

IshKebab 1y ago

> being workshopped with the C++ community Honestly seems like a dubious idea. The C++ community that remains are even more "just get good" than before. They still think UB all over the place is fine.

bla3 1y ago
I think that might be true of the language committee, but there's presumably a huge crowd of people with existing c++ code bases that would like to have a different path forward than just hoping that the committee changes priorities.
- pjmlp 1y ago
  That is what many of us have done moving into managed languages, with native libraries when required to do so. The remaining people driving where the language goes have other priorities in mind like reflection. The profiles that were supposed to be so much better than the Safe C++ proposal, none of them made it into C++26, and it remains to be seen if we ever will see a sensible preview implementation for C++29.
  - tialaramex 1y ago
    C++ 26 doesn't have the technology, but it wouldn't matter anyway because what's crucial about Rust isn't the technology it's the culture. If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does. Beyond that though, the profiles idea is dead in the water because it doesn't deliver composition. Rust's safety composes. Jim's safe Activity crate, Sarah's safe Animals crate and Dave's safe Networking crate compose to let me work with a safe IPv6-capable juggling donkey even though Jim, Sarah and Save have never met and had no idea I would try that. A hypothetical C++ 29 type safe Activity module, combined with a thread safe Animals module, and a resource leak safe Networking module doesn't even get you something that will definitely work, let alone deliver any particular safety.
    - marsven_422 1y ago
      [dead]
    - pjmlp 1y ago
      Yeah, that sums it all quite nicely, see contracts proposal as a good example of that.
    - justcuriousab 1y ago
      > If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does. But Rust allows pattern matching on floats. https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a732d173c98ece1e58b3272015d1dae6 https://play.rust-lang.org/?version=stable&mode=debug&editio... Rust Zulip is C++ WG21 confirmed?
GuB-42 1y ago
I'd say the C++ community is torn. Some part of it want C++ to be Rust, with a focus on compile-time safety. Others take "C++" literally as "C with extra stuff" and value performance over safety. Companies like Google are likely to be in the former camp, as for what they are doing, security is critical. Unsurprisingly, Carbon is a Google project. Video game companies on the other hand are likely to be in the latter camp. Most of the times, security is not as critical, especially for offline games, and memory corruption usually don't go further than a game crash. Tight memory management however is critical, and it often involves raw pointers and custom allocation schemes.
- JonChesterfield 1y ago
  I blame the "we won't recompile anything ever" stance from the financial organisations for the breakdown. It means C++ cannot fix mistakes, even when they harm performance, under the general name of "abi stability". Thus there is an opening for a faster language. And still for a safer one. And for an easier one to use. So all C++ has going for it is inertia. It's moribund unless the committee reconsider their stance on intentionally losing the performance competition.
  - Buttons840 1y ago
    Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages? A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust. There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common. (Maybe Rust could do this, but they haven't stabilized their ABI yet, and I don't the details.) [0]: https://faultlore.com/blah/c-isnt-a-language/ https://faultlore.com/blah/c-isnt-a-language/
    - Gibbon1 1y ago
      I remember reading that google tried to impress on WG21 and 14 the need to update the ABI and they were utterly opposed. The result is google is no longer interested in C++. Apple I think is also no longer interested in C++. I think also Swift now has a stable ABI.

wocram 1y ago

Carbon is just trying to bring a rust-like edition to cpp, there's no reason for non cpp users to Carbon.

pjmlp 1y ago

Main goal for Carbon is to port existing code first, general purpose second, with Google internal teams as main customer. If it ever goes beyond that remains to be seen. The Carbon team is the first to point out that anyone doing green field development should reach out to Rust or any managed language that fits the project scope.

chandlerc1024 1y ago

> What _is_ interesting is that I get the impression that Carbon is being workshopped with the C++ community, rather than the wider PLT community -- I worry that they won't benefit from the broader perspectives that'll help it avoid well-known warts elsewhere. FWIW, we're working hard whenever looking at an aspect of the language to look at other languages beyond C++ and learn any and everything we can from them. Lots of our design proposals cite Swift, Rust, Go, TypeScript, Python, Kotlin, C#, Java, and even Scala.

steveklabnik 1y ago
Make sure you're checking out Hylo. I'm not sure that its ideas are right for Carbon, but if you're looking for a credible alternative to Rust's take on safety, I think it's one of the better ones.
- chandlerc1024 1y ago
  We've been watching closely since before the name change. =D Had lots of conversations with several of the folks involved.
sour-taste 1y ago
Chandler I would love to be involved in Carbon development to shape its development to be usable at my company or alternatively to use it in my own projects. What is the best way to stay involved in Carbon development? Just the discord?
- chandlerc1024 1y ago
  In increasing order of volume of material: - Our newsletter / announcements via GitHub Discussions[1] email[2] or RSS[3] - The "Last Week in Carbon" posts via GitHub[4] or RSS[5] - The Discord server: https://discord.gg/ZjVdShJDAs https://discord.gg/ZjVdShJDAs [1]: https://github.com/carbon-language/carbon-lang/discussions/categories/announcements https://github.com/carbon-language/carbon-lang/discussions/c... [2]: https://groups.google.com/a/carbon-lang.dev/g/announce https://groups.google.com/a/carbon-lang.dev/g/announce [3]: https://github.com/carbon-language/carbon-lang/discussions/categories/announcements.atom https://github.com/carbon-language/carbon-lang/discussions/c... [4]: https://github.com/carbon-language/carbon-lang/discussions/categories/last-week-in-carbon https://github.com/carbon-language/carbon-lang/discussions/c... [5]: https://github.com/carbon-language/carbon-lang/discussions/categories/last-week-in-carbon.atom https://github.com/carbon-language/carbon-lang/discussions/c...