5 ms·

Afaik Clang development has massively slowed down since Google gave up on trying to improve C++ as a language (it required breaking ABI, which the C++ standards

Afaik Clang development has massively slowed down since Google gave up on trying to improve C++ as a language (it required breaking ABI, which the C++ standards committee rejected). They moved on and created Carbon instead for future C++ development where they need to work with existing C++ code, and recommend Rust for greenfield development.

nindalf 4y ago
Was clang development so dependent on one organisation? I can easily believe that many Google engineers are choosing to spend their time on Carbon now, but it seems strange that there was so much dependence here. Could there be some other reason for clang lagging behind?
- pjmlp 4y ago
  Yes, it was also dependent on Apple's contributions, which nowadays focus on Swift and Objective-C. If you look at the C++ versions being used across Apple's platforms, they are more than happy staying with C++17 (Metal Shading Language is even lower, based on C++14). Almost everyone else seems to care only about LLVM, otherwise how to explain that LLVM gets almost as many contributions per year as the Linux kernel, while clang is lagging so much behind?
Dylan16807 4y ago
From what I am aware of, google wanted to break API significantly, not just ABI, by changing a bunch of standard library guarantees.
- AngriestLettuce 4y ago
  Good. It is high time for some breakage. When your toe is gangrenous, you should cut it off, even if you're sad to see it go. This applies doubly so if you're as strange and mysterious a beast as C++ is — sprouting body parts in random places seemingly overnight, only incidentally producing anything valuable. Maybe you don't actually need a thumb in your forehead in the first place, especially since it bleeds into your eye whenever you try to use it.
  - witx 4y ago
    > sprouting body parts in random places seemingly overnight, only incidentally producing anything valuable. Maybe you don't actually need a thumb in your forehead in the first place, especially since it bleeds into your eye whenever you try to use it I've been using c++ for a while, and this comment is perhaps the best and funniest description of what I think about the language but was never able to put into words. Kudos for the laughs!
joatmon-snoo 4y ago
Far more likely to me is that bringing libc++ up to C++20 standards isn't important for google3. Carbon is a O(10y) project, not a O(3y) project. * absl strings provides the same compile-time guarantees that <format> does * absl date/time libs have integrations with the proto time types * google3 has many threading & synchronization primitives that it prefers over the STL types (all of which already has integrations with fleet-wide performance monitoring and other toolchain customizations, e.g. deadlock detection), so there isn't much reason to move the threading libraries forward
- Dylan16807 4y ago
  > Carbon is a O(10y) project, not a O(3y) project. So are C++ language updates.
  - joatmon-snoo 4y ago
    Standard updates, not STL implementation.
- jimbob45 4y ago
  Shouldn't that be big Omega?

nindalf 4y ago

Was clang development so dependent on one organisation? I can easily believe that many Google engineers are choosing to spend their time on Carbon now, but it seems strange that there was so much dependence here. Could there be some other reason for clang lagging behind?

pjmlp 4y ago
Yes, it was also dependent on Apple's contributions, which nowadays focus on Swift and Objective-C. If you look at the C++ versions being used across Apple's platforms, they are more than happy staying with C++17 (Metal Shading Language is even lower, based on C++14). Almost everyone else seems to care only about LLVM, otherwise how to explain that LLVM gets almost as many contributions per year as the Linux kernel, while clang is lagging so much behind?

Dylan16807 4y ago

From what I am aware of, google wanted to break API significantly, not just ABI, by changing a bunch of standard library guarantees.

AngriestLettuce 4y ago
Good. It is high time for some breakage. When your toe is gangrenous, you should cut it off, even if you're sad to see it go. This applies doubly so if you're as strange and mysterious a beast as C++ is — sprouting body parts in random places seemingly overnight, only incidentally producing anything valuable. Maybe you don't actually need a thumb in your forehead in the first place, especially since it bleeds into your eye whenever you try to use it.
- witx 4y ago
  > sprouting body parts in random places seemingly overnight, only incidentally producing anything valuable. Maybe you don't actually need a thumb in your forehead in the first place, especially since it bleeds into your eye whenever you try to use it I've been using c++ for a while, and this comment is perhaps the best and funniest description of what I think about the language but was never able to put into words. Kudos for the laughs!

joatmon-snoo 4y ago

Far more likely to me is that bringing libc++ up to C++20 standards isn't important for google3. Carbon is a O(10y) project, not a O(3y) project. * absl strings provides the same compile-time guarantees that <format> does * absl date/time libs have integrations with the proto time types * google3 has many threading & synchronization primitives that it prefers over the STL types (all of which already has integrations with fleet-wide performance monitoring and other toolchain customizations, e.g. deadlock detection), so there isn't much reason to move the threading libraries forward

Dylan16807 4y ago
> Carbon is a O(10y) project, not a O(3y) project. So are C++ language updates.
- joatmon-snoo 4y ago
  Standard updates, not STL implementation.
jimbob45 4y ago
Shouldn't that be big Omega?