4 ms·

>Rewrite Linux Kernel in Rust? Rust has no backward compatibility: C code compiles fine after decades. It would be a waste of time to rewrite Linux in Rust when

>Rewrite Linux Kernel in Rust? Rust has no backward compatibility: C code compiles fine after decades. It would be a waste of time to rewrite Linux in Rust when the resulting code has a lifetime of few months until it won't compile and start breaking everywhere.

vog 9y ago
> C code compiles fine after decades Early C code doesn't compile on modern systems at all. Speaking of early C code, every vendor had their own version. C standardization had to go a long way. Even today, writing portable C code is hard. Need a portable 128-bit integer? Good luck on Windows. Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Oh, and int32_t was introduced in C99, which is not exactly "decades" ago, but admittedly that was 18 years ago. However, I wouldn't bet on portability of any code older than that, unless the authors of that C code were extremely careful and anticipatory. But then, with enough effort (and perhaps code generation), you can create portable code in any language. Rust skips all that mess, by having a clear experimental phase in the 0.x versions. It became stable with a clear commitment to backwards compatibility since 1.0, which was released in 2015.
- tom_mellior 9y ago
  > Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Citation needed. Which compilers for which machines are you talking about? I don't think any change the size of int. What does break is the assumption that int is the same size as pointers, but that's because the sizes of pointers change.
  - vog 9y ago
    Whoops. I meant 16-bit versus 32-bit integers, when switching from 16-bit to 32-bit systems. Sorry for the confusion. Fortunately, they didn't repeat that mess for 32/64 bits, at least not for integers, but "decades old code" is still affected.
    - tom_mellior 9y ago
      Ah, yes. I agree, that was a mess!
dbaupp 9y ago
Rust has had backward compatibility since 1.0: https://blog.rust-lang.org/2014/10/30/Stability.html https://blog.rust-lang.org/2014/10/30/Stability.html
- FrozenVoid 9y ago
  Servo and most projects use nightly which breaks it all the time.
  - redtuesday 9y ago
    But you wrote "Rust has no backward compatibility" who cares what libraries/projects do?
    - FrozenVoid 9y ago
      Rusrc nightlies are the compiler. The only notable compiler i am aware of. There is no standard, ecosystem or any -std=v1.0 that old code can rely on. >who cares People who want to invest time in Rust.
  - wtetzner 9y ago
    Servo might use nightly, but do you have evidence that most projects do? Especially after custom derive landed in stable, most of the reason for sticking with nightly dissappeared.
the_why_of_y 9y ago
> C code compiles fine after decades ... and then hilarity ensues at runtime due to latent UB that happened to "work" in the C implementation the original author used.

vog 9y ago

> C code compiles fine after decades Early C code doesn't compile on modern systems at all. Speaking of early C code, every vendor had their own version. C standardization had to go a long way. Even today, writing portable C code is hard. Need a portable 128-bit integer? Good luck on Windows. Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Oh, and int32_t was introduced in C99, which is not exactly "decades" ago, but admittedly that was 18 years ago. However, I wouldn't bet on portability of any code older than that, unless the authors of that C code were extremely careful and anticipatory. But then, with enough effort (and perhaps code generation), you can create portable code in any language. Rust skips all that mess, by having a clear experimental phase in the 0.x versions. It became stable with a clear commitment to backwards compatibility since 1.0, which was released in 2015.

tom_mellior 9y ago
> Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Citation needed. Which compilers for which machines are you talking about? I don't think any change the size of int. What does break is the assumption that int is the same size as pointers, but that's because the sizes of pointers change.
- vog 9y ago
  Whoops. I meant 16-bit versus 32-bit integers, when switching from 16-bit to 32-bit systems. Sorry for the confusion. Fortunately, they didn't repeat that mess for 32/64 bits, at least not for integers, but "decades old code" is still affected.
  - tom_mellior 9y ago
    Ah, yes. I agree, that was a mess!

dbaupp 9y ago

Rust has had backward compatibility since 1.0: https://blog.rust-lang.org/2014/10/30/Stability.html https://blog.rust-lang.org/2014/10/30/Stability.html

FrozenVoid 9y ago
Servo and most projects use nightly which breaks it all the time.
- redtuesday 9y ago
  But you wrote "Rust has no backward compatibility" who cares what libraries/projects do?
  - FrozenVoid 9y ago
    Rusrc nightlies are the compiler. The only notable compiler i am aware of. There is no standard, ecosystem or any -std=v1.0 that old code can rely on. >who cares People who want to invest time in Rust.
- wtetzner 9y ago
  Servo might use nightly, but do you have evidence that most projects do? Especially after custom derive landed in stable, most of the reason for sticking with nightly dissappeared.

the_why_of_y 9y ago

> C code compiles fine after decades ... and then hilarity ensues at runtime due to latent UB that happened to "work" in the C implementation the original author used.