You seem to like C++. Look at the C++ direction of travel. Lifetime annotation? Rust has it, Bjarne now wants it in C++. Volatile access? Rust has it as methods read_volatile and write_volatile, and C++ is moving away from "cv qualfier" towards that same approach. Modules? Rust has them. C++ is now getting them. Backwards compatibility? Rust has editions, C++ is trying to do epochs.
C++ has spent years trying to argue that "Good" C++ won't have all the terrible problems, and so far it just hasn't worked out that way. I think the backward compatibility nightmare will consume C++ faster than it can try to dig itself out.
Here's the biggest problem: The people who can't leave C++ for Rust are also most invested in the features that prevent C++ from evolving to compete with Rust. If you're programming x86-64 machines with a C++20 compiler, you could go to Rust anyway, you'd be excited about a C++23 with lifetime annotation and epochs, but not so excited that you will throw effort at helping that to happen rather than Rust. Whereas if you're programming a specialist DSP and you're looking forward to getting C++ 17 next year when your vendor offers it, you can't move to Rust easily because there is no Rust for your DSP (yet?) but you also don't care about C++23 because your compiler vendor hasn't even announced a C++20 compiler yet.
> If you're programming x86-64 machines with a C++20 compiler, you could go to Rust anyway...
No I won't, because the ecosystem that makes me reach out for C++ when not using either Java or .NET based languages doesn't exist for Rust.
Unreal/Unity class game tooling, CUDA/SYSCL class GPGPU programming, WinUI/QT/VCL class GUI frameworks, JUCE/openFrameworks/Cinder creative coding tools, LLVM/Gimple,...
So C++ with static analysers is still the way to go for those of us that don't care about building an ecosystem from scratch and rather focus on deliverables.
Just a correction: Im not implying that Rust have no virtues, it has a lot, and its a very strong candidate to write new projects into whenever you think you need C++.
I would and will consider Rust always, and it probably will make sense to use instead. If my former post implied that i dont like Rust, im correcting here, because i like it and i thinks its cool technology and that it have virtues C++ don't have.
I was saying that, specially now that the language is more mature theres a thriving community around it, it can go by virtue..
C++ is where it is now because of its "killer apps". OS's, Browser, Games, a great amount of complex software with millions of lines of code.
And they are not garbage that need to be replaced. Rust taking over by virtue will be by creating killer apps in it. Showing itself as a great replacement for projects that can also be coded in C++.
Security folks invested in Rust saying that all new code in Android will now be coded in Rust its not replacing by virtue as important things like domain knowledge and getting used to a tool is also very important, and it will probably go away. Security is just one thing that is important in a project, its not the only one. But of course if you let the security folks decide, other important aspects will not be taken into account (I tought it was a really bad move by the way, as other problems not linked to security will appear with time).
Nobody with influence agrees with this assessment. Without taking the bait on this "C++ software is garbage" stuff: there's general acceptance that some significant chunk of memory-unsafe software, particularly the stuff most exposed to attack, or that runs on the systems we're most concerned with being attacked, needs to be replaced with memory-safe alternatives.
It is simply not the case that Rust's only role is in "new killer apps". Replacing C++ code is part of the raison dêtre of Rust.
You knew this was a pointless dead argument the moment Linus Torvalds began entertaining Rust kernel modules. The debate is over. That doesn't mean --- regardless of what any website says --- that all C++ software is "garbage", or that anyone is going to pry C++ out of your cold, dead hands. But it does make arguing about whether the maintainer of curl should accept funds to replace some of their code with Rust tedious and unproductive.
There is, yet WinUI selling point is that it is written in C++, just like macOS DriverKit and Metal.
I am betting with you how Microsoft will tout the C++ trumpet on the Windows 11 Developer talks next week, despite their timid approach to Rust on some of their tools now.
So the marketing message goes something like this,
Microsoft Security Response Center puts out a guideline that states:
1 - Use .NET languages, Java, Go if you can afford a GC
2 - Adopt Rust otherwise
3 - If C++ must be used, take care and adopt C++ Core Guidelines
WinUI team,
"WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease."
I should also note that .NET is migrating their C++ code into C#, as they improved the language to add the features available on Sing# and System C#.
" In this release, we’ve continued, and even accelerated, the process of porting native implementations in the coreclr runtime from C/C++ to instead be normal C# managed code in System.Private.Corelib."
C++ force is too strong on WinDev, the very fact that Windows is the only mainstream OS that still doubles down on a C++ based GUI framework kind of proves it.
I am really curious if Windows 11 will finally be more like Apple and Google platforms, or keep going down this path of making certain APIs only available in C++, while forcing .NET devs to manually wrap them.
It looks like virtue to me.
You seem to like C++. Look at the C++ direction of travel. Lifetime annotation? Rust has it, Bjarne now wants it in C++. Volatile access? Rust has it as methods read_volatile and write_volatile, and C++ is moving away from "cv qualfier" towards that same approach. Modules? Rust has them. C++ is now getting them. Backwards compatibility? Rust has editions, C++ is trying to do epochs.
C++ has spent years trying to argue that "Good" C++ won't have all the terrible problems, and so far it just hasn't worked out that way. I think the backward compatibility nightmare will consume C++ faster than it can try to dig itself out.
Here's the biggest problem: The people who can't leave C++ for Rust are also most invested in the features that prevent C++ from evolving to compete with Rust. If you're programming x86-64 machines with a C++20 compiler, you could go to Rust anyway, you'd be excited about a C++23 with lifetime annotation and epochs, but not so excited that you will throw effort at helping that to happen rather than Rust. Whereas if you're programming a specialist DSP and you're looking forward to getting C++ 17 next year when your vendor offers it, you can't move to Rust easily because there is no Rust for your DSP (yet?) but you also don't care about C++23 because your compiler vendor hasn't even announced a C++20 compiler yet.