bluescarni

I am not really seeing how the first chart can be construed as AI disrupting the junior job market...

The 22-25 red line had plateaued before the release of ChatGPT and was already trending downwards by the time ChatGPT appeared.

Additionally, it took a quite a while before vibe and agentic coding appeared and gained traction, and I cannot really see how the precipitous decline between say Jan 2023 and Jan 2024 can be attributed mainly to AI.

The "other" reasons mentioned later in the post seem much more convincing.

> Thusly, what happens in code that accesses the string after the move is UB.

No, it is implementation-defined behaviour.

> In the implementation of C++ the article uses the string was just empty. But for all we know it may still contain a 1:1 copy of the original or 20 copies or a gobbledygook of bytes.

Yes, and if you want to make sure that the string is empty before you do something else with it, you just use a clear() (which will be optimised away by the compiler anyway).

Or, if you prefer, you can assign another string to it, or anything else really.

> Any code that relies on the string being something (even empty) may behave different if it isn't. That's the very definition of UB.

No it is not.

> "A typical implementation strategy" is meaningless for someone writing code against a language specification.

Then don't rely on that specific implementation detail and make sure that the string is in the state you want or, even better, don't touch the moved-from string ever again.

> So apparently, move does not prevent generation of a copy, but the empty string instead of expected text “Dave” is very interesting. Apparently, after termination of show after the move, the object is invalidated. This does not affect the Person object, but only the string object. Recognize that I speak about a factual behavior on the hardware. I think we have undefined behavior here. And no compilation error.

There is a lot of wrong in this paragraph:

- a "copy" was not generated, at least not in the sense that the actual content of the string was copied anywhere;

- there's no undefined behaviour here and no invalidation of the string. Standard library types are required to be left in an unspecified but valid state after move. "Valid" here means that you can go on and inspect the state of the string after move, so you can query whether it is empty or not, count the number of characters, etc. etc. "Unspecified" means that the implementation gets to decide what is the status of the string after move. For long enough strings, typical implementation strategy is to set the moved-from string in an empty state.

As if typical HN comments were any better than typical reddit comments...

> Most FSD buyers seem aware they’re paying into a research effort.

Shades of Star Citizen right there.

"Hacker" news, ladies and gentlemen.

It's eerily reminiscent of the x86 bashing that was going on in the early 2000s, only that in those days PPC was seen as the superior (new, baggage-free) ISA by Apple fanboys.

Then Apple switched to x86, and from day to night we witnessed the magnificent spectacle of the entire Apple fanbase performing a whiplash-inducing collective pirouette towards the narrative that, after all, x86 was not so bad.

My initial comment was correcting a factually inaccurate statement regarding CPU performance.

It is you who barged into the thread with unrelated GPU performance numbers, but whatever :)

Those are Tensor flops, the numbers for the Zen CPU are "general-purpose" flops (sometimes called "vector flops" in marketing material).

The vector flops for the 3090Ti are 33 TFlops for single precision, 0.5 TFlops for double precision. So, 16x faster than the 5950x in single precision, 2x slower for double precision. At almost 3x the price and >4x the power consumption.

Of course, if all you care about is AI, then there's no argument - but then we are not really talking about a general-purpose device any more.

The narrative of GPUs being "hundreds of time" faster than CPUs is vastly blown out of proportion for general-purpose computing.

Eh?

My 5950x (measured) flops are ~2 TFLOPS in single-precision, ~1TFLOPS in double precision (obviously, due to half the SIMD vector size). This is a desktop-class 16-core machine.

> Does anyone honestly think politicians in a specific part of the world are not corrupt?

Just because American democracy is failing, it does not mean democracy is failing everywhere.

Another new lambda feature in C++20 is default constructability. I am surprised this is not mentioned in the article.

> If that's your main example, you are in for a ride. Since asutton branch is over 15 years old almost at this point, and it was by design that no work should happen in LLVM until concepts make it into the standard.

Nice strawman, what does this have to do with anything that I wrote?

You went on and on about how there's heaps of "LLVM PhDs" (whatever that might mean) coming out of academia, so I gave you an example of someone working in academia who developed and contributed a key C++ feature to GCC.

> I can give you a dozen examples, from constexpr, metaclasses, coroutines, modules, etc. where things made it much earlier into LLVM than GCC.

That's not my experience, and I have been using GCC and Clang daily on modern C++ codebases targeting the latest standard for the last 10 years.

> From 2005 to 2014 GCC development severely stagnated, being much slower than clang, having horrible error messages when compared to clang, etc.

Yes, GCC's diagnostics have been trailing Clang's, though they have mostly caught up in the last few versions. But "much slower than clang" is flat out wrong, unless you mean compile-time performance. GCC has for years consistently produced more optimised code than Clang's, and it only in the last couple of years that the two compilers are essentially on performance parity.

> AMD, Intel, ARM, ... they all have proprietary toolchains built on LLVM, and send and merge multiple diffs to LLVM upstream, every day.

I seriously doubt that AMD/Intel/ARM engineers are doing substantial work on C++20 features, but I'd be happy to be proven wrong :)

> On top of that, many technology companies have built their whole platforms on top of LLVM.

That is irrelevant, as most of those companies are keeping their modifications to LLVM closed-source. They are not at all interested in fostering a healthy open-source ecosystem around LLVM.

> GCC doesn't really have that.

This is just wrong. Just as a single example, the first ever C++ concepts implementation was written for GCC by Andrew Sutton, a University professor and co-author with Bjarne of the concepts proposal. LLVM's implementation came years later, and it's not as stable or complete to this day.

> If Red-Hat and other private companies withdraw support, there are really few people familiar enough with GCC to keep it afloat, few people interested in learning and contributing because that won't land them industry jobs, etc.

Again, no. There is nothing in the 30+-years long history of GCC that suggests that this would happen.