3 ms·

No, there’s lots of technical reasons why. Not least of which is that c/c++ has be try very loose aliasing rules as well as the lack of a concept of move/drop (

No, there’s lots of technical reasons why. Not least of which is that c/c++ has be try very loose aliasing rules as well as the lack of a concept of move/drop (language nerds can chime in with all the other reasons). Even c++ would struggle even though committed members are aware c++ is dying and are trying to bridge the gap somehow. If you changed the language to support a Rust-like borrow checker, you’d lose back compat which defeats the purpose of stick with C semantics in the first place. There’s the related problem that the borrow checker isn’t automatic. There are places it does good inference, but any structure that has ownership needs to have that owner ship explicitly defined (and often in functions too). That is hard to do when you have to deal with a lot of legacy code that doesn’t have it - while that part can be solved through annotations, things inexpressible in the Rust borrow checker are perfectly legal C so you’d somehow also have to change that code. Additionally the Rust borrow checker can still fail spectacularly on very reasonable code. That’s being addressed in Polonius if that project ever lands, but even then it’s just a step function improvement to solve specific what should be valid code - it doesn’t fix all issues with the borrow checker. C++ is exploring gradual safeness to provide for optionally strengthening the safety but it’s unclear that approach actually makes sense other than as a balwark to c++ dieing completely (ie the switching cost would be weighed against the cost of fortifying the safety of the code and relying on a poor estimate of the risks involved since there’s too many unknowns) TLDR: structural, cultural, and back compat issues will prevent anything like the borrow checker.

adastra22 3y ago
Why do you think C++ is dying? Maybe in your industry, but not in general.
- 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 ago
    Game 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 ago
      What 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 ago
        I 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 ago
        Yeah 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.

adastra22 3y ago

Why do you think C++ is dying? Maybe in your industry, but not in general.

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 ago
  Game 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 ago
    What 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 ago
      I 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 ago
        Yeah 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.