With reflection and code generation coming to C++26, and the already existing constexpr/consteval machinery, C++ will be able to do all of this.
Mein Fuehrer, Dieses feature... dieses feature wird von MVCC nicht eingebaut.
What do you mean by that ?
C++ adding the same features means it'll be possible, but it has a much larger intersection of alternative features to introduce edge cases with, and _many_ implementations that will have this feature with varying quirks: all of this means C++ will have to do a _much_ better job than Zig does here to achieve nearly the same result.
I think both will be nice.
Hmm. Actually, now that makes me want to learn Zig.
I bet a Fortran 77 developer will think the same of Fortran 2023, a COBOL 60 developer of COBOL 2023, a K&R C developer from C23, a 1975 Scheme developer from R7RS, a Python 1.0 developer from Python 3.13,... even Go 1.0 developers from 1.24 with generics, generators,...
This lets the language throw away bad ideas, without throwing away the code people wrote in the era when we didn't realise that's a bad idea.
It doesn't cover standard library, scenarios with binary libraries doing cross calls across epochs and several others.
I still don't see it any different from a language version switch like in many other languages, specially in JVM and .NET ecosystem.
Languages with good macro systems have the upper hand in that regard.
Which is what people always forget when comparing language grammars.
Rust has had an almost usable implementation for affine types, and being the second coming of Ada, to win the hearths of the industry, including all major OS vendors and hyperscallers.
Go got lucky with Docker and Kubernetes rewrites, and their adoption across the industry.
So far Zig is basically Modula-2 with C like syntax, and compile time execution, relies on the same tooling that C and C++ have had for decades for use-after-free, doesn't support a binary libraries ecosystem by design, and really Bun isn't going to be the killer project that triggers a Rewrite in Zig movement.
It remains to be seen if Zig 1.0 happens, and how its adoption story at scale will be like.
But people really, REALLY want to get off c and c++ for all the numerous reasons everybody knows.
Any language that's older than 10 years is going to make questionable life choices. It's very easy to be Captain Hindsight, and ask why didn't you do X, 5 years ago? But adding feature X also makes another feature or property impossible, either via opportunity cost or features/properties being at odds.
That said, what do you mean by questionable life choices?
Yes, true. Every language has to make some early foundational choices, as few as possible, and try to carefully think about any new addition to the core because of the extra congnitive load that comes with it.
Go is an extreme example here, leaning towards the conservative side. C as well. Zig. Not a fan of Java but it also is kinda slow to add things. Python used to be very careful as well but that epoch is gone.
C++ is the opposite example. It tries to add as much as possible, and it was always the case. C compatibility! And classes! Templates! RAII! Metaprogramming! More of everything! Until it reached a point where it's unforgiving hard to add things. Or even learn it properly.
Now, Rust feels like a C++ reimplementation, complete with a culture of adding as much as possible as quickly as possible, and ignoring the resulting cognitive load.
I mean, it's a choice. Rust definitely has some great, even amazing, ideas to it. But I am afraid of thinking what the language will feel like in 10 years.
Ok, but I did ask for what specifically do you mean by questionable life choices? I feel Java is moving at a fast pace (and adding everything and the kitchen sink). Hence, why I wanted specific examples. Can you separate your feelings from facts, and see from where the feelings come from? I'm not saying you're wrong, I'm saying I want to understand your basis for that.
> Go is an extreme example here, leaning towards the conservative side.
Is it? Didn't it also start adding features that it swore not to add (generics)?
I mean, there are things I like: bits taken from the ML language family, tooling, sane approach to OOP, error handling.
But the culture of trying to pull everything in... It is a road to hell.
The difference between Rust and Go here is that Go took 10 years to come up with a generics proposal, and it does solve a massive problem with the language.
> But the culture of trying to pull everything in... It is a road to hell.
What part do you mean? Is it async? I'm as well very critical of it as well.
Or do you mean. Const? The compile time reflections?
I've already mentioned things that are universally praised.
I don't like having 2 macro systems, async, convoluted syntax and also am not sure that the (unsafe) consequences of using a borrow checker are worth it.
To me Rust sounds like the story of C++ (or Common Lisp) all over again: what if we add all the cools stuff? Like, ALL THE THINGS. And Rust is a single implementation language. Nothing limits the speed of thought!
Additionally extensions from Turbo C, Borland C, MSVC C, xlC, aC, Green Hills C, TI C, ARM C, Microbit C, clang C, GCC C,Intel C, CUDA C, ISPC,OpenCL C, Renderscript C...
But in all honesty, starting with ANSI C and onwards the language itself didn't change all that much, at least not in the same way C++ did. C99 was a serious cleanup but that's about it.
Go the language evolves at a similar pace, most things happen outside of the core.
Now what's interesting is that C++ is (almost) all C's quirks multiplied by the latest things WG21 decides to pull into the language. And WG21 does indeed add a lot.
At some point I just lost the point of it all.
It might be enough to make the zig ecosystem viable. This along with tiger beetle (they have raised tens of millions).
I think a lot of time is spent right now on the tooling, I hope that in a near feature the zig team will be able to switch to the event loop / standard library topics which really need love.
Also it is quite telling that outside IDE friendly languages, debbugers are kind of stuck in the 80's, so no wonder that many think 80% of Visual Studio and friends is good enough.