[pjmlp]

My point about Python is that it is always presented as begginer friendly language, yet is it quite complex for anyone that whats to fully master it.

The language + standard library + C API references are around 2392 pages, not counting the other minor documentation like the 500 PEPs, release notes and differences across each Python release, even minor ones.

Then there is the whole set of meta-classes, decorators, mixins, generators, operator overloading, multiple inheritance, abstract classes, fp like programming and much more.

The big difference to C++, is that the community doesn't care about performance, leaving the PyPy guys a Quixotic battle regarding adoption, which isn't the case with C++ compilers.

Even C isn't as simple as many think, with its 200+ documentated cases of UB, and the days that C mapped 1:1 to PDP 11 Assembly are long gone.

How C code looks like, and what gets generated via auto-vectorization, GPGPU code, SIMD intrisics are very much two worlds appart.

[thezilch]

You're absolutely right that Python has also become more and more complex and often not for the best.

As for Python performance, on the contrary, I think there was a large portion of the Python community that did care during my years with it. I think 3.x adoption was hurt a lot by being slower than 2.7.x. I think a lot of the community jumped ship to Golang or similar, for both performance and complexity reasons.

I would absolutely love for C++ to tackle C UB or make incompatible insecure C. Instead, we get stuff like Ranges, time and again. I'm struggling to understand what complexities you are finding it covers that are worth supporting forever, committing gray matter, committing productivity loss, committing debug travesties, &c. Say I'm a musician that can hold complete compositions in my head; why should I commit this feature and its baggage to memory?

[pjmlp]

> Say I'm a musician that can hold complete compositions in my head; why should I commit this feature and its baggage to memory?

Because C++ is the sane alternative to C on OS SDKs, HPC, GPGPU programming, regarding portable code.

Now, ideally as memory safe systems advocate, I would like to see more of Swift, .NET Native, D, Go, Rust, Java (AOT), OCaml, ...

However, when using languages not endorsed by vendors, it always means inferior IDE/debugging experience, lacking IDE support, manually writting FFI integration code, tracking down which layer is responsible for certain bugs,..., so switching to something that looks easier turns out to become harder in the long run as the whole stack experience suffers.

There are already signs of OS vendors finally improving a bit the situation, with Apple continuously pushing for Swift, Google restricting what is at all possible to do with NDK, Windows teams focusing on .NET Native in spite of C++/WinRT (nee C++/CX), Rust adoption by all big names.

However we are still at least a decade away of any of those languages enjoying a similar industry position in platform SDKs as C++ enjoys nowadays, after 30 years fighting against C.

So I rather keep that baggage in memory, while doing my best to use modern C++, alongside the other more type safe languages, also part of the respective platform SDKs, than additing additional attrition to my production code toolbox.

I imagine my opinion is not unique.