4 ms·

> there is no reason for replace C with Rust. If you have some reason to choose C today, I'm not sure Rust is a contender to stand in as a replacement. They ar

> there is no reason for replace C with Rust. If you have some reason to choose C today, I'm not sure Rust is a contender to stand in as a replacement. They are vastly different languages. That doesn't mean there is rejection that C's memory model is unsafe, just that there isn't a "better C" recognized to choose from.

quectophoton 4y ago
IMHO Rust could be a good replacement for C when (if) it gets an actual spec, or at least when (if) there are multiple real implementations of the compiler (meaning, with borrow checker, compiler errors, and all). Because otherwise, you could write Rust 2018 edition (for example), and there's nothing preventing a situation where your currently-valid Rust-2018-edition program stops compiling (or behaves differently) on a future version of rustc even when compiling to that specific edition, just because some behavior is (in the future) considered a compiler bug or something. And it would be perfectly valid to cause such breakage, because there's no definition of "what is Rust", other than "what this specific compiler in this specific version accepts". I'm not talking about whether such possible backwards-incompatible change on a Rust edition would be good or bad. Just that with the current monoculture around a single implementation, there's not many guarantees. A specification, or multiple implementations, would at least add some (good) friction. I'm not denying its current value as a safe language; just that, as it is now, I don't consider it as a good choice for programs that must stay alive for decades, like `curl` or an operating system.
- dralley 4y ago
  >just because some behavior is (in the future) considered a compiler bug or something Unsound behavior is considered a compiler bug, and is liable to change if you accidentally rely on it. I would hope that having multiple compilers won't change that. The motivation to actually fix soundness holes is one of the primary differentiators of Rust. That said, these are very rare.
  - quectophoton 4y ago
    I would even expect that having multiple implementations would help catch small things that might have been missed in the reference implementation. I'm looking forward to Ferrocene's specification and the gccrs implementation.
- com2kid 4y ago
  Rust is not a C replacement, it is a C++ replacement. Many of the people writing code in C do not want to use C++. And many of the embedded use cases for C already involve very careful memory usage. If you've banned malloc and don't have threads, you've removed a huge swath of common bug sources right off the bat. For someone writing code to setup registers on a DMA controller, Rust has nearly 0 benefit. (That said, no one should be writing new command line utilities in C, parsing arbitrary data in C is dangerous!)
  - steveklabnik 4y ago
    Not everyone agrees with this characterization, including some well known (now former) C developers: http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/ http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-...
    - com2kid 4y ago
      Excellent post, thanks for linking. The arguments made for replacing C with Rust seem sound.
- nindalf 4y ago
  > need multiple implementations This thinking is understandable but it’s basically pattern matching. There were two successful languages that followed this model and so a language that seeks to replace them should adopt the same model of design by committee followed by multiple independent implementations. But there’s no reason to think that a language needs multiple implementations to succeed. Python has had one implementation used by all its user and that hasn’t prevented from becoming a top 3 language by usage. Ditto with other very popular languages like Go, Ruby, TypeScript, C#. I don’t understand the concern that your code will stop compiling with a future version of the compiler. Firstly, Rust hasn’t broken backwards compatibility in 8 years and doesn’t plan to in future. Secondly, why do you need to upgrade the compiler? If it works on the current version you can continue to use that in perpetuity. Honestly, having multiple implementations would be a curse. I see nothing but negatives. Even the smallest proposals (like embedding data in a binary) take a decade to get buy in and 3-4 years to be implemented. Convincing everyone of the benefit of a feature is just too difficult so a lot of good ideas are never put forward, let alone implemented. And the difficulty of getting it working across compilers and operating systems. How hard is it to write C++20 code that will compile with all major compilers on all major OSs? On Rust it’s trivial. To put it simply - it’s trivial to answer the question “is this Rust code valid?” If rustc compiles it, it’s valid today and will always be valid (modulo bugs). You want alternate implementations? There’s a WIP - gcc-rs. But thankfully they haven’t forked the semantics of the language. It should and shouldn’t compile all code that rustc does and doesn’t. Otherwise it’s a bug in gcc-rs. Anything else would make the life of Rust users painful. In summary, multiple implementations is a bad idea for many reasons. If you can express the benefit beyond “that’s the way C and C++ do it”, I’m eager to listen. But please explain how Python and Go managed to succeed with one impl.
  - pjmlp 4y ago
    C# has a ECMA standard and several implementations.
    - quectophoton 4y ago
      I was surprised when I found out that Ruby is ISO/IEC 30170:2012 [1]. [1]: https://www.iso.org/standard/59579.html https://www.iso.org/standard/59579.html

quectophoton 4y ago

IMHO Rust could be a good replacement for C when (if) it gets an actual spec, or at least when (if) there are multiple real implementations of the compiler (meaning, with borrow checker, compiler errors, and all). Because otherwise, you could write Rust 2018 edition (for example), and there's nothing preventing a situation where your currently-valid Rust-2018-edition program stops compiling (or behaves differently) on a future version of rustc even when compiling to that specific edition, just because some behavior is (in the future) considered a compiler bug or something. And it would be perfectly valid to cause such breakage, because there's no definition of "what is Rust", other than "what this specific compiler in this specific version accepts". I'm not talking about whether such possible backwards-incompatible change on a Rust edition would be good or bad. Just that with the current monoculture around a single implementation, there's not many guarantees. A specification, or multiple implementations, would at least add some (good) friction. I'm not denying its current value as a safe language; just that, as it is now, I don't consider it as a good choice for programs that must stay alive for decades, like `curl` or an operating system.

dralley 4y ago
>just because some behavior is (in the future) considered a compiler bug or something Unsound behavior is considered a compiler bug, and is liable to change if you accidentally rely on it. I would hope that having multiple compilers won't change that. The motivation to actually fix soundness holes is one of the primary differentiators of Rust. That said, these are very rare.
- quectophoton 4y ago
  I would even expect that having multiple implementations would help catch small things that might have been missed in the reference implementation. I'm looking forward to Ferrocene's specification and the gccrs implementation.
com2kid 4y ago
Rust is not a C replacement, it is a C++ replacement. Many of the people writing code in C do not want to use C++. And many of the embedded use cases for C already involve very careful memory usage. If you've banned malloc and don't have threads, you've removed a huge swath of common bug sources right off the bat. For someone writing code to setup registers on a DMA controller, Rust has nearly 0 benefit. (That said, no one should be writing new command line utilities in C, parsing arbitrary data in C is dangerous!)
- steveklabnik 4y ago
  Not everyone agrees with this characterization, including some well known (now former) C developers: http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/ http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-...
  - com2kid 4y ago
    Excellent post, thanks for linking. The arguments made for replacing C with Rust seem sound.
nindalf 4y ago
> need multiple implementations This thinking is understandable but it’s basically pattern matching. There were two successful languages that followed this model and so a language that seeks to replace them should adopt the same model of design by committee followed by multiple independent implementations. But there’s no reason to think that a language needs multiple implementations to succeed. Python has had one implementation used by all its user and that hasn’t prevented from becoming a top 3 language by usage. Ditto with other very popular languages like Go, Ruby, TypeScript, C#. I don’t understand the concern that your code will stop compiling with a future version of the compiler. Firstly, Rust hasn’t broken backwards compatibility in 8 years and doesn’t plan to in future. Secondly, why do you need to upgrade the compiler? If it works on the current version you can continue to use that in perpetuity. Honestly, having multiple implementations would be a curse. I see nothing but negatives. Even the smallest proposals (like embedding data in a binary) take a decade to get buy in and 3-4 years to be implemented. Convincing everyone of the benefit of a feature is just too difficult so a lot of good ideas are never put forward, let alone implemented. And the difficulty of getting it working across compilers and operating systems. How hard is it to write C++20 code that will compile with all major compilers on all major OSs? On Rust it’s trivial. To put it simply - it’s trivial to answer the question “is this Rust code valid?” If rustc compiles it, it’s valid today and will always be valid (modulo bugs). You want alternate implementations? There’s a WIP - gcc-rs. But thankfully they haven’t forked the semantics of the language. It should and shouldn’t compile all code that rustc does and doesn’t. Otherwise it’s a bug in gcc-rs. Anything else would make the life of Rust users painful. In summary, multiple implementations is a bad idea for many reasons. If you can express the benefit beyond “that’s the way C and C++ do it”, I’m eager to listen. But please explain how Python and Go managed to succeed with one impl.
- pjmlp 4y ago
  C# has a ECMA standard and several implementations.
  - quectophoton 4y ago
    I was surprised when I found out that Ruby is ISO/IEC 30170:2012 [1]. [1]: https://www.iso.org/standard/59579.html https://www.iso.org/standard/59579.html