Every project must colonize a valley of the language, declare a dialect, and bit-fiddle their own thing.

It might be a measure of popularity, but not of unity.

However it would be imperative for a push such as Carbon[1] to be similar to the kotlin to Java. A modernisation that simplifies , maintains backwards/forwards compatibility and reuses established libraries and tooling.

This however will need a entity that can champion and push it forward with a strong enough project to anchor it in the mainstream.The transitions are doable ,like Android dev from plain java to kotlin , or in OSX moving from Objective-C to Swift.

Additionally borrowing a robust batteries type standard library to reduce the sprawl of coding options and funnel greenfield projects into best practices and less boilerplate.

[1] https://www.infoworld.com/article/2337225/beyond-c-the-promi...

with the caveat that i know it could be better. at this point i just think it's simpler than some of the stuff out there from a 'whats happening underneath the hood' perspective

I take a very different view about the trajectory of languages given the current trends in software development. The more people rely upon agentic coding processes, the more they will demand faster compilation which will increasingly become a significant bottleneck on product velocity. The faster the llms get, the more important it is for the tools they use to be fast. Right now, I still think we are in an uncanny valley where llms are still slow enough that slow tooling does not seem that bad, but this is likely to change. People will no longer be satisfied asking their agent to make a change and come back in a minute or an hour. They will expect the result nearly instantaneously. C++ (and rust) compile times are too slow for the agent to iterate in the human reaction window so I believe that one of two things will happen over the next few years: llm progress will stall out or c++ and rust will nosedive in popularity.

- The current CPP version is extremely bloated

- CPP is not going away anytime soon

- The rise of Rust/Go/Zig is not fighting for CPP's seat

- You can target CPP code using any of these aforementioned languages

- Rust has never claimed to be "safer", it just makes it harder to write unsafe code

I lack a degree though

That's not really plausible. Unfortunately this is all you get on the methodology:

> Our methodology is based on two main pillars. First, we make use of reliable sources of developer numbers or direct indicators of their activity. This includes the number of GitHub accounts, Stack Overflow accounts, and employment statistics from the USA and the European Union. Second, we rely on our Global Developer Survey data, where we directly measure developer activity. So far, we've run 29 waves of this large survey, and in each, we reach more than 10,000 developers globally. We combine these two main sources to derive our estimates.

Plenty of space for them to screw up I think.