9 ms·

I'm only learning Rust, but the borrow checker and ownership and lifetimes could be duplicated in C with a little extra syntax, couldn't they?

vlovich123 3y ago
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.
jraph 3y ago
By patching C like this, wouldn't you end up with Rust or something very similar before you know it?
- xvedejas 3y ago
  safe Rust isn't just the borrow checker, it's also: - no uninitialized memory - clone vs copy semantics as part of the type system - Send, Sync, "fearless concurrency" - no unchecked indexing - type safety (you can't just cast things like in C) I do think these are clear complements to a borrow checker, since it's all in the interest of preventing undefined behavior. Yet, there are even more nice modern features of Rust that C lacks: - hygienic macros - namespaces - pattern matching - modern build/package system
  - jraph 3y ago
    Good point.
  - carlmr 3y ago
    Also proc_macros. Often Rust ends up easier to read than Python due to proc_macro abstractions, too. Serde is a great example for this. Rust is really high-level when you use it correctly. And I rarely need lifetime annotations. Which is especially easy if you write in a somewhat functional style.
favorited 3y ago
It could, but we're just now getting `bool`, `true`, and `false` as keywords in C23. The children of everyone posting here will be dead & buried before WG14 adds lifetimes to C's type system.
- jraph 3y ago
  But at least, our grandchildren's graves won't be unsafely accessed.
MaulingMonkey 3y ago
People can and have added extra annotations to C and C++ code for such things. Static analyzers can catch some use-after-free and iterator invalidation bugs at compile time. Problem is: • They're opt-in instead of opt-out (meaning none of your system libraries or 3rd party dependencies have bothered using them.) • What's been implemented in practice frequently fails to find bugs in relatively simple toy examples (I often confuse myself wondering why I've failed to turn some new bit of static analysis on, when in fact I have, and it's simply failed to catch even my demonstration bug.) • The effective tools, on the other hand, tend to have "false" positives as well. The conclusion I've come to is that to fully solve these problems in C or C++, you'd effectively transform it into a new language. And at that point, you might as well stop pretending that's not exactly what you're doing, and actually create said new language. --- That said, when stuck using C or C++, static analysis and the compiler-specific half measures that are available are worth using, IMO. • https://awesomekling.github.io/Catching-use-after-move-bugs-with-Clang-consumed-annotations/ https://awesomekling.github.io/Catching-use-after-move-bugs-... • https://clang.llvm.org/docs/ThreadSafetyAnalysis.html https://clang.llvm.org/docs/ThreadSafetyAnalysis.html • https://clang.llvm.org/docs/AttributeReference.html#lifetimebound https://clang.llvm.org/docs/AttributeReference.html#lifetime... • https://github.com/MaulingMonkey/notes/blob/master/programming/cpp-inspired-by-rust.md https://github.com/MaulingMonkey/notes/blob/master/programmi... • `printf` type checking annotations exist, but don't necessairly work on MSVC. Often sanest to make your legacy logging macros call `printf` in a dead branch to leverage any hardcoded type checking of `printf` Basically everything is a warning that you might consider cranking up to an error, of course.
- Someone 3y ago
  > The effective tools, on the other hand, tend to have "false" positives as well. That’s true for rust, too, with the difference being that rust won’t compile false positives. I haven’t used rust or recent C++ much, but it wouldn’t surprise me if the false positives that C++ gives had significant overlap with cases where the equivalent rust code would not compile.
  - estebank 3y ago
    An example of this could be trying to mutably access disjoint parts of a Vec. The Rust language today doesn't understand that is safe today, because it would require tracking all indices used somehow to verify that the accesses are indeed disjoint. But you can write unsafe code to access those fields, or even better, use Vec::split_at_mut() which uses the unsafe code you'd have to write with the appropriate precondition checks to ensure you can't misuse it in a way that causes memory unsafety.
demurgos 3y ago
They could, but for compatibility reasons it would be opt-in. The strength of Rust is that you can't opt out of the borrow-checker (even with unsafe).
saagarjha 3y ago
No. This would require a significant change to the semantics of C.

vlovich123 3y ago

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.

jraph 3y ago

By patching C like this, wouldn't you end up with Rust or something very similar before you know it?

xvedejas 3y ago
safe Rust isn't just the borrow checker, it's also: - no uninitialized memory - clone vs copy semantics as part of the type system - Send, Sync, "fearless concurrency" - no unchecked indexing - type safety (you can't just cast things like in C) I do think these are clear complements to a borrow checker, since it's all in the interest of preventing undefined behavior. Yet, there are even more nice modern features of Rust that C lacks: - hygienic macros - namespaces - pattern matching - modern build/package system
- jraph 3y ago
  Good point.
- carlmr 3y ago
  Also proc_macros. Often Rust ends up easier to read than Python due to proc_macro abstractions, too. Serde is a great example for this. Rust is really high-level when you use it correctly. And I rarely need lifetime annotations. Which is especially easy if you write in a somewhat functional style.

favorited 3y ago

It could, but we're just now getting `bool`, `true`, and `false` as keywords in C23. The children of everyone posting here will be dead & buried before WG14 adds lifetimes to C's type system.

jraph 3y ago
But at least, our grandchildren's graves won't be unsafely accessed.

MaulingMonkey 3y ago

People can and have added extra annotations to C and C++ code for such things. Static analyzers can catch some use-after-free and iterator invalidation bugs at compile time. Problem is: • They're opt-in instead of opt-out (meaning none of your system libraries or 3rd party dependencies have bothered using them.) • What's been implemented in practice frequently fails to find bugs in relatively simple toy examples (I often confuse myself wondering why I've failed to turn some new bit of static analysis on, when in fact I have, and it's simply failed to catch even my demonstration bug.) • The effective tools, on the other hand, tend to have "false" positives as well. The conclusion I've come to is that to fully solve these problems in C or C++, you'd effectively transform it into a new language. And at that point, you might as well stop pretending that's not exactly what you're doing, and actually create said new language. --- That said, when stuck using C or C++, static analysis and the compiler-specific half measures that are available are worth using, IMO. • https://awesomekling.github.io/Catching-use-after-move-bugs-with-Clang-consumed-annotations/ https://awesomekling.github.io/Catching-use-after-move-bugs-... • https://clang.llvm.org/docs/ThreadSafetyAnalysis.html https://clang.llvm.org/docs/ThreadSafetyAnalysis.html • https://clang.llvm.org/docs/AttributeReference.html#lifetimebound https://clang.llvm.org/docs/AttributeReference.html#lifetime... • https://github.com/MaulingMonkey/notes/blob/master/programming/cpp-inspired-by-rust.md https://github.com/MaulingMonkey/notes/blob/master/programmi... • `printf` type checking annotations exist, but don't necessairly work on MSVC. Often sanest to make your legacy logging macros call `printf` in a dead branch to leverage any hardcoded type checking of `printf` Basically everything is a warning that you might consider cranking up to an error, of course.

Someone 3y ago
> The effective tools, on the other hand, tend to have "false" positives as well. That’s true for rust, too, with the difference being that rust won’t compile false positives. I haven’t used rust or recent C++ much, but it wouldn’t surprise me if the false positives that C++ gives had significant overlap with cases where the equivalent rust code would not compile.
- estebank 3y ago
  An example of this could be trying to mutably access disjoint parts of a Vec. The Rust language today doesn't understand that is safe today, because it would require tracking all indices used somehow to verify that the accesses are indeed disjoint. But you can write unsafe code to access those fields, or even better, use Vec::split_at_mut() which uses the unsafe code you'd have to write with the appropriate precondition checks to ensure you can't misuse it in a way that causes memory unsafety.

demurgos 3y ago

They could, but for compatibility reasons it would be opt-in. The strength of Rust is that you can't opt out of the borrow-checker (even with unsafe).

saagarjha 3y ago

No. This would require a significant change to the semantics of C.