Hacker News Reader

Comment by gpderetta | Hacker News Reader

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.

View on HN

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...

Reply on news.ycombinator.com