5 ms·

I tried to write a kernel in rust but reverted back to c. I just feel that it is not very nice systems language. The entire time i felt like i was fighting to m

I tried to write a kernel in rust but reverted back to c. I just feel that it is not very nice systems language. The entire time i felt like i was fighting to manipulate the language into doing something it wasn't supposed to do.

gwerbin 9y ago
Would you be able to go into more detail on this? An example maybe? It might be useful for someone like me who's "interested in Rust" but hasn't tried it (yet).
- steveklabnik 9y ago
  There's also a lot of us who do enjoy writing kernels in Rust; https://os.phil-opp.com/ https://os.phil-opp.com/ goes through the start of ones for x86_64, and really shows off some nice features about Rust.
- Sag0Sag0 9y ago
  The amount of unsafe code necessary for low level work, the difficulty in sending a stream of bytes to an io port and the innate complexity of the language. C's philosophy is everything is a series of bits which you can manipulate at will. Rust's is the same except you have to through a huge amount of hoops first to make things "safe". Things like converting a String to an i64 are a pain. There is large amount of boilerplate code needed. All in all this is a personal preference. I prefer some unsafeness in c to (in my opinion) the constant inconvenience of programming in rust.
  - Rusky 9y ago
    Those sound like relatively straightforward things to write safe and convenient wrappers for. Obviously not as barebones as C but certainly not constantly fighting the language.
    - Sag0Sag0 9y ago
      True. I suppose i just prefer the bare bonededness.
      - hossbeast 9y ago
        This slogan could sell a lot of T shirts.
  - comex 9y ago
    I know it's just one example, and you're reporting more of a general impression, but since you mentioned converting a String to an i64… well, in what way? If you mean reading the bytes of the string as an i64, that's unsafe { *(s.as_ptr() as *const i64) } ...which is a bit more verbose than C's *(int64_t *) ptr but not that verbose, especially given that there will often be more code in the unsafe block. On the other hand, in C that's often technically undefined behavior due to strict aliasing, so to get strictly conformant code you have to use memcpy. Rust has no strict aliasing. (I wouldn't actually recommend the above Rust code, because it doesn't verify that the string's length matches i64 - but neither does C, so it's a fair comparison. More idiomatic wrappers can be found in third-party crates like byteorder or pod.) If you mean casting the pointer to the bytes to an i64, that's s.as_ptr() as i64 which doesn't seem verbose. (No unsafe needed in that case.)
    - oconnor663 9y ago
      There are safe interfaces for this stuff too. The byteorder crate (not in the standard library, but widely used) has: let i = NativeEndian::read_i64(...); Or if you're literally parsing a string of digits: let i: Option<i64> = digits.parse(); The `parse` method on strings is a particularly smooth piece of trait system magic.
    - makapuf 9y ago
      > to get strictly conformant [C] code you have to use memcpy couldn't you use an union there ? > Rust has no strict aliasing. does that mean that rust cannot optimize for things C could ? (real quesiton I don't know rust)
      - oconnor663 9y ago
        > does that mean that rust cannot optimize for things C could? Here's my best understanding of the situation. Someone who actually understands the compiler might have to correct me: - Pointers in unsafe Rust don't do any strict aliasing optimizations, which C compilers sometimes do. The Rust memory model isn't fully specified, though, and the status quo seems to be related to not actually passing type information to LLVM. Not clear whether this will change in the future. There's some discussion of it here: http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-tootsie-pop-model-for-unsafe-code http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-... - References in safe Rust (the vast majority of code) have much stronger aliasing information than pointers do in C. This is one of the core features of Rust, that references that allow mutation are guaranteed not to be aliased. I think the status quo is that this information isn't passed to LLVM because of some LLVM bugs getting in the way, but that it should start working in the near future. When all of this is working, I think it should produce code that's faster than C, in the same way that Fortran sometimes does.
TrueSelfDao 9y ago
Would you say there is a certain level of abstraction above which rust seemed to work somewhat smoothly?
- Sag0Sag0 9y ago
  Honestly i would not know. I have only used rust in a very low level context.
  - alexnewman 9y ago
    Could the problem be that you have very little rust experience and a lot of experience writing c?

gwerbin 9y ago

Would you be able to go into more detail on this? An example maybe? It might be useful for someone like me who's "interested in Rust" but hasn't tried it (yet).

steveklabnik 9y ago
There's also a lot of us who do enjoy writing kernels in Rust; https://os.phil-opp.com/ https://os.phil-opp.com/ goes through the start of ones for x86_64, and really shows off some nice features about Rust.
Sag0Sag0 9y ago
The amount of unsafe code necessary for low level work, the difficulty in sending a stream of bytes to an io port and the innate complexity of the language. C's philosophy is everything is a series of bits which you can manipulate at will. Rust's is the same except you have to through a huge amount of hoops first to make things "safe". Things like converting a String to an i64 are a pain. There is large amount of boilerplate code needed. All in all this is a personal preference. I prefer some unsafeness in c to (in my opinion) the constant inconvenience of programming in rust.
- Rusky 9y ago
  Those sound like relatively straightforward things to write safe and convenient wrappers for. Obviously not as barebones as C but certainly not constantly fighting the language.
  - Sag0Sag0 9y ago
    True. I suppose i just prefer the bare bonededness.
    - hossbeast 9y ago
      This slogan could sell a lot of T shirts.
- comex 9y ago
  I know it's just one example, and you're reporting more of a general impression, but since you mentioned converting a String to an i64… well, in what way? If you mean reading the bytes of the string as an i64, that's unsafe { *(s.as_ptr() as *const i64) } ...which is a bit more verbose than C's *(int64_t *) ptr but not that verbose, especially given that there will often be more code in the unsafe block. On the other hand, in C that's often technically undefined behavior due to strict aliasing, so to get strictly conformant code you have to use memcpy. Rust has no strict aliasing. (I wouldn't actually recommend the above Rust code, because it doesn't verify that the string's length matches i64 - but neither does C, so it's a fair comparison. More idiomatic wrappers can be found in third-party crates like byteorder or pod.) If you mean casting the pointer to the bytes to an i64, that's s.as_ptr() as i64 which doesn't seem verbose. (No unsafe needed in that case.)
  - oconnor663 9y ago
    There are safe interfaces for this stuff too. The byteorder crate (not in the standard library, but widely used) has: let i = NativeEndian::read_i64(...); Or if you're literally parsing a string of digits: let i: Option<i64> = digits.parse(); The `parse` method on strings is a particularly smooth piece of trait system magic.
  - makapuf 9y ago
    > to get strictly conformant [C] code you have to use memcpy couldn't you use an union there ? > Rust has no strict aliasing. does that mean that rust cannot optimize for things C could ? (real quesiton I don't know rust)
    - oconnor663 9y ago
      > does that mean that rust cannot optimize for things C could? Here's my best understanding of the situation. Someone who actually understands the compiler might have to correct me: - Pointers in unsafe Rust don't do any strict aliasing optimizations, which C compilers sometimes do. The Rust memory model isn't fully specified, though, and the status quo seems to be related to not actually passing type information to LLVM. Not clear whether this will change in the future. There's some discussion of it here: http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-tootsie-pop-model-for-unsafe-code http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-... - References in safe Rust (the vast majority of code) have much stronger aliasing information than pointers do in C. This is one of the core features of Rust, that references that allow mutation are guaranteed not to be aliased. I think the status quo is that this information isn't passed to LLVM because of some LLVM bugs getting in the way, but that it should start working in the near future. When all of this is working, I think it should produce code that's faster than C, in the same way that Fortran sometimes does.

TrueSelfDao 9y ago

Would you say there is a certain level of abstraction above which rust seemed to work somewhat smoothly?

Sag0Sag0 9y ago
Honestly i would not know. I have only used rust in a very low level context.
- alexnewman 9y ago
  Could the problem be that you have very little rust experience and a lot of experience writing c?