Hacker News Reader

Comment by darknavi | Hacker News Reader

Maybe I am behind in the times but it was a little surprising to me to see MSVC have full C++20 support while GCC and Clang are still trying to get there.

View on HN

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.

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?

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?

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

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.

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

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

> Carbon is a O(10y) project, not a O(3y) project.

So are C++ language updates.

Standard updates, not STL implementation.

Shouldn't that be big Omega?

It is not surprising given the licenses, that the two major clang contributors decided to focus elsewhere (Swift, Objective-C and Carbon), while everyone else[0] is happilly just consuming clang, and only contributing to LLVM.

At least GCC has Red-Hat supporting ISO C++ improvements.

[0] - ARM, Intel, Embarcadero, IBM, NVidia, IBM, Nintendo, Sony,...

But Red Hat is IBM, nowadays.

Also AFAIK IBM is one of the most dedicated supporters of C++ in general.

Yes and no, while IBM owns Red-Hat, it doesn't dictate how Red-Hat does their own business decisions.

Not in what concerns ISO C++ support, and if it was up to IBM, trigraphs would still be supported.

See what ISO version their xl compilers support, across all mainframe, Aix and Linux deployments.

https://en.cppreference.com/w/cpp/compiler_support

> Yes and no, while IBM owns Red-Hat, it doesn't dictate how Red-Hat does their own business decisions.

Even that's true, it's now IBM's money that gets invested.

> Not in what concerns ISO C++ support, and if it was up to IBM, trigraphs would still be supported.

I know about the trigraphs. That they were fighting for that shows imho exactly that IBM is heavily invested in C++. They have a shitload of old but hightly important code that can't be migrated realistically.

So IBM will keep throwing money on C++ to extend its live infinitely, I guess.

You forgot to mention IBM

Microsoft does a pretty good job there. clang has been lacking behind ever since google reallocated resources somewhere else.

What bothers me most about C++ is that it's mostly old people now. All the young people who are actively involved in language design, tool development, ... are putting their effort into other languages.

There are young people still specially those wanting to work in cool domains like game development, however many older ones have some vested interests in keeping C++ the way it is, hence why even advocating for security is such an uphill battle.

Or see how WinDev is so resistent to change, instead of providing .NET like tooling for C++, like Borland/Embarcadero have done for the last 25 years, they stick to their ways of manually editing IDL files and COM.

While I agree the young people who work on the languages and frameworks are increasingly working with other languages. The rust crowd is much younger than the people who are publicly working on popular C++ frameworks.

In 10 years, there won't be many people left working on C++ as a language and on the tooling.

Might be, but until Microsoft et all rewrite their tooling in Rust, there will be enough people to keep C++ going.

And if it changes, so be it, I am not coding today as I was in 1986, when I typed my first LOAD "".

> but until Microsoft et all rewrite their tooling in Rust, there will be enough people to keep C++ going.

At least Microsoft started to do exactly this. They started to touch the Win API even to create Rust bindings. Because MS saw that this is the only way to future prove this stuff.

Other big players, like IBM, don't look like they're moving, though. But OK, IBM moves so slowly as a pitch drop falls. So maybe we just don't see them moving.

Those Rust bindings are a joke for any serious Windows development.

If you feel like C++/WinRT development experience is bad, good luck with Rust/WinRT.

And since it is the same team leads, which clearly have proven that they don't care about developer productivity, given how they have managed the C++/CX to C++/WinRT transition, I wouldn't wait too much out of it.

Yes, Microsoft is Microsoft.

And I've heard rumors the Win team is an issue in general. (As the product they ship).

But they're at least moving. And the direction is clear.

What's wrong about old people?

The problem are people that don't want to change anymore. But this trait is independent form age in my experience.

But nevertheless, that C++ doesn't attract new developers may have reasons indeed. C++ refuses to get substantially modernized. In the long run such a stance will attract less and less people I think.

C++ would need a fresh start without all the baggage collected through several decades of backwards compatibility. A C++v2 is overdue, imho.

Only then it would find itself eventually competing with other new languages, without the current killer feature that reads "we can run ancient code". I'm not sure most people behind C++ are keen on such a challenge.

> What's wrong about old people? > > The problem are people that don't want to change anymore. But this trait is independent form age in my experience.

Nothing is wrong with old people. That's not what I was trying to say but people in their 50s or 60s will not be working for much longer. I don't think there will be many people left working __on__ C++ and its tooling in 10 years.

> But nevertheless, that C++ doesn't attract new developers may have reasons indeed. C++ refuses to get substantially modernized. In the long run such a stance will attract less and less people I think.

I think there are some pretty nice additions in the recent standards but all the backward compatibility is definitely a problem for the development of the language.

C++ is basically a "do it all" language and it feels like newer languages have rather specific use cases which they excel in.

> I don't think there will be many people left working __on__ C++ and its tooling in 10 years.

I would also extrapolate this form how things look now.

But in a sense the language has deliberately chosen that way.

> C++ is basically a "do it all" language and it feels like newer languages have rather specific use cases which they excel in.

Yes, I also see this.

I'm not really happy with that as I think it's easier to learn one "real general purpose language" properly than have shallow knowledge in two dozens of glorified DSLs.

But C++ isn't this language for me either. I personally would love to see Scala (v3) to become a better general purpose language. It's modern with a lightweight syntax, it's powerful (up to compile time verification of your code), it can embed all kinds of DSLs (which makes dedicated external DSLs superfluous), now it starts even to "run everywhere", but it's slow(er) and fat(er) compared to C++, Rust, and the other contenders in some very important areas, which sadly rules it out for many tasks.

> But in a sense the language has deliberately chosen that way.

Agreed, which is a pity but it is what it is.

> But C++ isn't this language for me either. I personally would love to see Scala (v3) to become a better general purpose language. It's modern with a lightweight syntax, it's powerful (up to compile time verification of your code), it can embed all kinds of DSLs (which makes dedicated external DSLs superfluous), now it starts even to "run everywhere", but it's slow(er) and fat(er) compared to C++, Rust, and the other contenders in some very important areas, which sadly rules it out for many tasks.

I have been doing C++ for the last 6 years now for scientific computing so safety wasn't the first priority, but chasing pointers while debugging is certainly no fun.

Recently, I have been getting into Rust and I really like what I have seen so far, at least for my use cases.

If you rephrase it, kind of sounds bad. What bothers you about C++ is that it's mostly experienced people now?

Has been the case for the past half decade, too.

MSVC's stdlib has been open-sourced, and MSVC is used by plenty of companies writing games, native Windows software, etc.

Not fully open-sourced. There are bunch of pieces that are available only in compiled form - .obj/lib files. Like math.h functions.

Reply on news.ycombinator.com