3 ms·
Every major tech organization has indicated their shifting focus of their flagship products to shift the codebases from c/c++ to rust. Microsoft (Windows, Azure
by vlovich123 3y ago
Every major tech organization has indicated their shifting focus of their flagship products to shift the codebases from c/c++ to rust. Microsoft (Windows, Azure maybe office, not sure), Google (Chrome and probably a bunch of internal projects), Apple (various kernel pieces to harden and fix the ability to jailbreak). Linux has dipped its toe in the water with drivers but honestly I expect that to shift away from C and then eventually C will go into a “no new subsystem in C” policy followed by a “rewrite critical subsystems in pure rust).
Dying doesn’t mean that there’s not going to be developers. It just means that it’s no longer growing and the ability to hire developers that have significant c/c++ experience will get harder and harder. It’s still very early days and c/c++ has a lot more legacy code still running than COBOL ever did and COBOL is still alive and kicking in a sense. I would still classify cobol as a largely dead language even though technically people still know it and the code is running.
As for industry, could be. I imagine you think finance but I have a hard time seeing them stick to c/c++ if the rest of tech proper has switched. For new projects, maintenance will be cheaper because of things like cargo crates and other ecosystem niceties that c/c++ will never have. And rust performance is on par with c/C++. So what would be the case for starting any new project in c/C++?
I’m not predicting a timeline. I’m just describing a clear trend. It could easily take 50+ years. Depends on investments by corporations + grass roots + how effective the c++ committee is at stopping the bleeding + whether the rust community does an own goal like trying to standardize the language through ISO which is a huge contributor for why c++ and c will be unable to adjust. But right now rust has a clear velocity and acceleration advantage and has achieved “escape” velocity for when a language will likely take over for another.
- adastra22 3y agoGame industry is solidly C++ and that’s not changing anytime soon. It’s not just inertia. Games have very specific latency and timing requirements that required tightly integrated language and compiler features developed for this very purpose. The financial industry too has similar needs and solutions. Rust isn’t a fit for those use cases. Not without a mountain of work that no one is doing, nor would be likely to be accepted as it conflicts with the design goals of Rust.
- crq-yml 3y agoWhat the games industry needs is a language packing a disruptive, 10x advancement to get away from C++. There are a lot of accumulated ideas right now that could make, perhaps, a 3x-5x difference, and are reasonably well-represented when looking at stuff like Zig, Nim, Odin, Beef, Jai, and others trying points along the frontier of "possible games languages". I think Zig stands the best chance of turning the corner by attacking the problems at the very base of the build system, libc, etc. Doing that opens up the floodgates for experimentation over a new base layer, and that will get you to a 10x change.
- SleepyMyroslav 3y agoI don't think games have any problems with build systems or libc. Source I am working in gamedev for some time. I simply do not see your stated 3x-5x difference. Would love to be proven wrong.
- adastra22 3y agoYeah build systems and such are a solved problem in the game industry, where build issues are self contained by the engine which often has custom tooling. If there is any killer feature it is probably at the intersection of coroutine execution of programmable script elements. Lua, one of the most commonly game scripting languages, leaves a lot to be desired. But not many projects are looking at the requirements of games here. The next generation of language will probably come from within the industry, from something like Unity’s Burst compiler, Unreal’s Verse language, or an evolution of rvscript into a JIT compiled fast backend.
- estebank 3y ago> Rust isn’t a fit for those use cases. Not without a mountain of work that no one is doing, nor would be likely to be accepted as it conflicts with the design goals of Rust. Could you elaborate?
- adastra22 3y ago
- pjmlp 3y agoIn Microsoft's case, it is still baby steps outside Azure. When XBox, Office and Windows business units really do approach Rust support the same way as they embrace C++ over anything else, then Rust is really in the house. Yes I am aware of Rust/WinRT and the GDI regions kernel module rewrite. Rust/WinRT is done by the same guys that botched C++/WinRT, no big hopes with that one.
- vlovich123 3y agohttps://www.theregister.com/2023/04/27/microsoft_windows_rust/ https://www.theregister.com/2023/04/27/microsoft_windows_rus... https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/ https://www.theregister.com/2024/01/31/microsoft_seeks_rust_... Reasonable people can disagree but I wouldn’t call that a baby step. Core windows libraries, the NT kernel all being rewritten in Rust. Not sure why 365 stuff is being rewritten from c# to rust but maybe there’s some kind of perf issues that Rust will help them with. But your bar is also too high. This stuff happens slowly and then all at once. The slow bit is making the infra changes and figuring out how to start the porting process so that other people can start to contribute in a way that’s a positive addition.
- pjmlp 3y agoThe only kernel stuff I already mentioned, there isn't anything else. On Office side, is yet again Azure infrastructure, which I also referred.