Comments 10
It sounds familiar. But even I have read something similar, it definitely failed to impress me that time. This time is different, though.
Features like macros, header files, partial template specialization, SFINAE, and complex initialization rules make evolution extremely difficult.
Really? I mean - really evolution? I guess that are zero cost features. Does it really take measurable time for a preprocessor to do its job? To the contrary, C++ evolves making the number of cases where macros are necessary smaller and the number of cases where it is understood why macros are the right or best choice larger. And C++ is getting modules...
I know, since that surfaced in Dart, the only way macros can conflict with something - they make hot reload, at least the Dart style hot reload, impossible. That is bad for Dart because Flutter requires hot reload. It is not bad for C++ because C++ does not make the logical mistake Google has made with Dart prioritizing a single Flutter feature before the general structure of the language. I am glad that no single C++ usage scenario can cannibalize all the rest.
As a result, the committee must either preserve backward compatibility (including dangerous UB) or introduce new parallel mechanisms, which further increases language complexity.
The dangers of UB are questionable, at least beyond the wonderful domain of marketing. I agree that adding anything to a language makes it bigger. I disagree that it increases complexity. Do adding keyboard shortcuts increase complexity of an app? Anything universal has to grow. For example, stdin >> and stdout << made C++ bigger and std::print made it bigger again, but I refuse to call that complexity. Was electric engineering made more complex with the addition of semiconductors?
Only features that barely conflict with anything can be added quickly.
How can that be different? Things conflict for a reason. Remember generics in Go? It took ten years to implement them not because of "conflicts" but because it was necessary to implement them right.
For a language that claims to be the primary tool for systems programming, this has become its Achilles’ heel.
How exactly? And who exactly claims C++ is the primary tool for systems programming and nothing else? That is exactly the same mistake Google has made - attempt to sacrifice everything for one feature, one scenario, one gang, be that UI polishing or systems programming. If that was a problem, C++ would be forked and we would have a system programming dialect.
C++ must be doing something exceptionally right since it is still one language, not that which, say, modern Lisp is.
This explains why new “C++ killers” appear regularly.
Which this? The only C++ killer wannabe I know is Zig. Everything else throws away something to facilitate something else. I found a perfect explanation and/or formulation of the logic in a book, Programminh in Lua. "The problems with multithreading arise from the combination of preemption with shared memory, so we can avoid them either using non-preemptive threads or not sharing memory." Wonderful. So, they say. That immediately leads to Go, and Rust, and Python... but not to a universal C++ replacement.
Modern C++ killers have forgotten a crucial historical lesson. The first C++ compiler, cfront, was a transpiler that converted C++ (“C with Classes”) into plain C.
First, it is not a lesson, it is survivor's bias. Second, being called a killer does not make one a killer. That languages successfully took certain domains where C++ still can be successfully used and nothing more.
I like Go. I see how Go can be a better choice than C++ in many, many cases. But it is sufficient to compile both to WebAssembly to see that Go is not a C++ killer in the article sense.
In contrast, modern replacements build their own compilers and ecosystems. While this gives better diagnostics and coherence, it creates a high compatibility wall. As a result, they become viable only for greenfield projects, not for gradually replacing C++ in massive legacy codebases.
Of course they do. Because they are not overall replacements, they are local ones. If all the friction on the boundaries of their domains is eliminated, nothing revolutionary happens.
The most realistic path to a true C++ replacement is a transpiler that generates C or, more likely, C++ as its output.
The most realistic path is to invent or discover something so great, that the idea of C++ replacement is justified. So far there are no new ideas that actually make computer programming better, all "innovation" is focused on the ways to hire cheaper people, or AI as off lately, to do the job where poor quality can be compensated for with excellent marketing.
Remember iPhone? It had been created not because Jobs was a genius but because many areas made significant progress that made iPhone possible. Because Jobs was a genius, it was Apple who created iPhone. Right now there is nothing C++ replacement can be based on.
When the time is ripe, transpilation is one of the options. What actually happens depends on the nature of the new ideas we know nothing about yet.
C++ itself won not because it was the best language, but because it integrated so easily with existing C infrastructure.
Yes. But transpilation was a minor benefit, while the ability to read C code, at least the headers, was the major one. At least my memories of the rise and fall of Delphi (strongly) suggest so. Anyway, all that historical lessons are passé now, AI changes or is likely to change everything. For example, why not to ask AI to rewrite all the C++ legacy?
Just curious, what's author's opinion on Fil-C ?
I’m familiar with this language and have explored its capabilities. Unfortunately, it implements the concept of runtime pointer management, which is incompatible with C++.
That's strange. Fil-C author says that his front-end is compatible with C++20 and most software can be compiled with Fil-C just find. From what I read, Fil-C is a kind of preprocessor for Clang/LLVM that inserts pointer checks (InvisiCaps) into intermediate representation of program (IR) during compile time. I liked the idea, but have not tried it yet. The problem with Fil-C for me is that it heavily depends on libmusl (a version of libc with pointer checks for Linux ABI), hence it's Linux-only. It will be difficult to port it to BSD or other OSes.
Fil-C author says that his front-end is compatible with C++20 and most software can be compiled with Fil-C just find.
That’s right. It’s call-compatible with C++, and I’m talking about the “don’t pay for what you don’t use” ideology. After all, it adds not just additional data, but additional address checking at runtime, a sort of garbage collector/analyzer.
Yes, that’s Clang the author is talking about. The idea is brilliant. I also did something similar to protect against application crashes due to stack overflows https://github.com/afteri-ru/stack-check
Yes, programs compiled with Fil-C said to be 4-times slower than with a regular compiler. That's a real drawback, but still faster than any Python or Java. And safe. :)
I’m working on a different approach to solving the problem of safety software development and performance - ensuring trusted at the level of programming language syntax and then translating the code into C++. https://github.com/afteri-ru/trust-lang
Well, new language (or new syntax) is always a problem. Devs don't like studying one more language, also there are tons of legacy code we depend on that will never be rewritten or even touched. In this regard Fil-C seems promising because it consumes already written code without modifications (mostly). Thanks anyway.
The Problems with C++ and Its Evolutionary Dead End