Hacker News Reader

Comment by qalmakka | Hacker News Reader

I think a large reason of why Clang lags behind in C++ standards is that Google and Apple don't really use modern C++ at all. Google has strict guidelines that prevent people to use half of the language (look at exceptions, for instance, without which most of the STL is crippled) and they use Abseil anyway, so they don't really care about the STL in the first place.

Apple on the other hand mostly uses C++ in very restricted scopes such as DeviceKit which are very limited and can't safely use the entire language anyway. Xcode-shipped Clang and libcxx are often pretty old, too. They don't really need C++ that much above what C++03 already had, so it's clearly an afterthought for them.

View on HN

C++ is great to have as much control over memory and performance as possible, while still providing more convenience than C. The C++ Standard Library and exceptions don't improve this control generally.

Possibly an unpopular opinion, but personally I wish the C++ Standard Library was kept separate from the C++ language and have the C++ committee focus on the language features instead.

My impression is that this is an opinion about the stdlib that many programmers concerned with performance share.

> Possibly an unpopular opinion, but personally I wish the C++ Standard Library was kept separate from the C++ language and have the C++ committee focus on the language features instead.

This is not an unpopular opinion.

Chromium finally switched to C++17 this year. The switch to C++20 will happen much sooner given that PNaCL support will be finally removed this summer.

That alone doesn't explain why clang conformance was very good till c++17 and then suddenly fell behind. The major clang contributors decided to focus their attention elsewhere,

One guess is because they didn't get what they wanted within the committee.

Google basically withdraw from clang after they lost the ABI vote, and Intel is now taking care of what used to be mostly Google stuff.

If I remember correctly some discussions on /r/cpp.

As for Apple, OP is right, Metal Shaders are based on C++14 dialect, IOKit/DriverKit use an Embedded C++ dialect, and for everything else there is Objective-C/Swift, and they only need enough C++ to use LLVM to develop them.

Was google pushing for breaking the ABI?

- a WG paper by a google employee regarding breaking the C++ ABI: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p186...

- A post about a C++ ABI break being voted against: https://cor3ntin.github.io/posts/abi/

I would not be surprised if google (or others in favor of breaking the ABI for the c++ standard library) would refocus on their alternate non-std std-replacement-ish library implementations (like abseil) instead given the lack of willingness to fix things in std proper from the committee.

Yeah, I've seen both of those before, but was unsure if it was just the position of a single Google employee or the position of google as a whole, as you made it sound like Google the company had actually taken such a stand

The permanent-ABI compatibility decision was effectively the death-knell for C++. Can't improve the standard library performance, making it effectively useless for the real world. Can't correct mistakes - the language and library warts grow and grow as the years pass by, making it impossible for beginners to pick up and learn the language.

Frankly, Google should fork C++ and create a new language without the warts and a new standard library.

> Frankly, Google should fork C++ and create a new language without the warts and a new standard library.

That's how we got golang.

Golang isn't really a C++ replacement, the performance metrics just aren't comparable. It's more of a Python replacement, for those applications where it would be just too slow, forcing you to write C or C++ because that's still the #1 way to accelerate your Python. Sure there are compilers such as Cython or Nuitka, but they just do not suffice when you _really_ need to speed up your code.

In C++‘s heyday there were things such as OKWS[0] web application server. Yes externally C++ was no so popular in such situations, but at Google they had/have many such C++ services and that was the motivation behind Go - a safe language to build mostly-IO-bound-but-a-little-bit-CPU-bound services.

Another example of this shift would be that Bitcoin’s reference impl (2009) is written in C++, whereas Ethereum’s reference impl (2015) is written in Go.

[0] https://okws.org/

They still mostly do, that is where Abseil is used.

Go has more mindshare outside Google than on Google's critical infrastructure.

The golang genesis story is that pike, thompson and company were so dissatisfied after a ISO C++ meeting that they just decided to make a C++ replacement that checked all the boxes they wanted. They got somethings wrong. They got somethings right. But, overall it was their NIH reaction to what would become "Modern C++".

> That's how we got golang.

I meant a language by removing all the warts, not removing all the features. :)

Seriously, if Go offered manual/arena memory management and real generic programming - stuff like template template parameters, STL algorithms, auto-vectorization, etc - it could effectively replace C++.

I still see a lot of google contributions to llvm recently. For example the mem* functions.

Yes. For example (there are a lot more) Vittorio's Epochs proposal P1881R1:

https://www.youtube.com/watch?v=PFdKFoQxRqM

Now, one of the things which you may have noticed really annoys C++ proponents here on HN is when people say "What Rust does..." and well, maybe Vittorio should not have done that in his talk. But the reason he's saying it is that although Rust has very few new ideas it popularises lots of existing ideas from PL theory that were not seen in the kind of languages C++ developers had experience with before.

A few slides in, Vittorio explains that he's not offering language fragmentation or dialects, an ABI break, or yet more stuff every programmer needs to learn. Nevertheless, criticisms of Epochs generally say that this is language fragmentation, it introduces dialects, it's an ABI break, and every programmer will have to learn all this extra stuff so it's hopeless...

Apple’s public/external-facing uses of C++ are restricted and odd (MSL, IOKit), but internally it seems pretty common in the OSes. Dyld, font rendering, and lower-level event handling (the remains of Carbon/HIToolbox) are all things I’ve seen in stack traces.

And of course there’s also WebKit and LLVM.

WebKit standard requires C++17, while LLVM still on C++14, so no pressure from Apple side to move forward,

https://webkit.org/languages-staged-08192020

https://llvm.org/docs/CodingStandards.html#c-standard-versio...

The Google style guide is public: https://google.github.io/styleguide/cppguide.html

I think reading it would convince you that the statement Google doesn't use modern C++ at all is false. It talks about modern features like CTAD.

Reply on news.ycombinator.com