5 ms·

What's your opinion on Rust? It seems to be successfully filling the niche Ada could not, even if Ada's problems were more political than technical.

hazz99 8y ago
I'm not a kernel programmer, and I haven't used Rust before, so take that into consideration. Some of my favourite things about Ada is it's approach to concurrency, which (I think) is far superior to other imperative concurrent languages like Go. We should never have to deal with low-level primitives like semaphores and mutexes - it's 2018! Why are we stuck in the 80s? I've heard that concurrency is difficult in Rust, but I've never used it, so I can't comment. I plan on learning very soon!
- dilyevsky 8y ago
  We should never have to deal with low level primitives like functions and variables - it’s 2018 why are we stuck in the 50s?
  - hazz99 8y ago
    That is an incorrect analogy. Semaphores are the "goto" statement of the concurrent world. Semaphores are not typed. They is no semantic connection to the thing they protect. Debugging concurrent systems with mutual exclusion enforced through these low-level primitives is a nightmare. If you forgot to lock/unlock, you'll never know! The compiler cannot check it. Deadlocks are imminent. We've had better abstractions since the 80s. Conditional critical regions, monitors, and (ideally) protected objects. Hell, even guards are better than semaphores and mutexes - at least they are associated with their critical region! I struggle to think of situations where a semaphore is the best choice. Maybe in extremely high-performance cases, but even then the compiler can usually make a better decision.
  - goatlover 8y ago
    Well, Alan Key pretty much said that in the 70s, and has stuck to his high level guns all this time.
- deckarep 8y ago
  Interesting comment...considering concurrency in Rust is significantly safer to do. This is the whole point of the borrow checker which is to ensure data-race free code. The story with concurrency is still being worked out with async server-side applications which is coming together swimmingly!
  - hazz99 8y ago
    > This is the whole point of the borrow checker which is to ensure data-race free code. That's awesome! I never knew Rust had safer concurrency. I'm quite keen to learn it - just waiting for the time.
- hazz99 8y ago
  Not sure why I'm downvoted for this. I struggle to think of a "modern" imperative language that offers similar levels of safety and concurrency, aside from possibly Rust. Erlang is fantastic, but not imperative. Go has channels, which is nice enough for message-passing behaviour, but nothing for elegantly sharing memory. ("Share memory by communicating" doesn't always work) Things like conditional critical regions, monitors, and protected objects are much better abstractions for concurrency.
  - atilaneves 8y ago
    > I struggle to think of a "modern" imperative language that offers similar levels of safety and concurrency, aside from possibly Rust. Erlang is fantastic, but not imperative. D
    - hazz99 8y ago
      Doesn't D just have message passing & mutexes? Which is fine, since D is supposed to be a better C. I wouldn't consider its concurrent primitives comparable to Ada. This is to be expected, since I don't believe they aim for such a nuanced level of concurrency. The Ada runtime is incredibly huge and complex - it was created by the US military, after all.
- marcosdumay 8y ago
  One of the talking points of Rust is fearless concurrency. Concurrency in Rust is not difficult (neither complex nor error-prone), but you have some high-level primitives that you must know how to choose and use.
jchw 8y ago
I hope Rust or Rust-like languages make it into the kernel, but I think it's worth noting that a huge problem right now is the toolchain and its dependencies. Go may have a better story here though I wouldn't bet on it being a more likely choice for kernel mode.
- wmf 8y ago
  What is the problem with the Rust toolchain?
  - eftychis 8y ago
    Same question: I am not sure go has solved the dependency problem at all.
    - jchw 8y ago
      When I said dependencies, I was not referring to dependency management. I was referring to the footprint of the toolchain. I'll reply to parent on what I meant in more detail, though.
      - eftychis 8y ago
        Ok! I see. Yes that is true. Thanks for the clarification.
  - jchw 8y ago
    Nothing at all, really, but kernel developers are going to be picky. For example, does LLVM target all of the architectures Linux supports today? Also, I think it's hard to sell Rust as a hard dependency of the Linux kernel when it isn't nearly as widespread as almost every other kernel dependency. I also sorta remember some kernel developers (not necessarily Linux) making a fuss about rustc using a huge amount of address space and not working on 32-bit systems for that reason - although frankly, I can't remember where I read that and I'm starting to question how much I'm misremembering there.

hazz99 8y ago

I'm not a kernel programmer, and I haven't used Rust before, so take that into consideration. Some of my favourite things about Ada is it's approach to concurrency, which (I think) is far superior to other imperative concurrent languages like Go. We should never have to deal with low-level primitives like semaphores and mutexes - it's 2018! Why are we stuck in the 80s? I've heard that concurrency is difficult in Rust, but I've never used it, so I can't comment. I plan on learning very soon!

dilyevsky 8y ago
We should never have to deal with low level primitives like functions and variables - it’s 2018 why are we stuck in the 50s?
- hazz99 8y ago
  That is an incorrect analogy. Semaphores are the "goto" statement of the concurrent world. Semaphores are not typed. They is no semantic connection to the thing they protect. Debugging concurrent systems with mutual exclusion enforced through these low-level primitives is a nightmare. If you forgot to lock/unlock, you'll never know! The compiler cannot check it. Deadlocks are imminent. We've had better abstractions since the 80s. Conditional critical regions, monitors, and (ideally) protected objects. Hell, even guards are better than semaphores and mutexes - at least they are associated with their critical region! I struggle to think of situations where a semaphore is the best choice. Maybe in extremely high-performance cases, but even then the compiler can usually make a better decision.
- goatlover 8y ago
  Well, Alan Key pretty much said that in the 70s, and has stuck to his high level guns all this time.
deckarep 8y ago
Interesting comment...considering concurrency in Rust is significantly safer to do. This is the whole point of the borrow checker which is to ensure data-race free code. The story with concurrency is still being worked out with async server-side applications which is coming together swimmingly!
- hazz99 8y ago
  > This is the whole point of the borrow checker which is to ensure data-race free code. That's awesome! I never knew Rust had safer concurrency. I'm quite keen to learn it - just waiting for the time.
hazz99 8y ago
Not sure why I'm downvoted for this. I struggle to think of a "modern" imperative language that offers similar levels of safety and concurrency, aside from possibly Rust. Erlang is fantastic, but not imperative. Go has channels, which is nice enough for message-passing behaviour, but nothing for elegantly sharing memory. ("Share memory by communicating" doesn't always work) Things like conditional critical regions, monitors, and protected objects are much better abstractions for concurrency.
- atilaneves 8y ago
  > I struggle to think of a "modern" imperative language that offers similar levels of safety and concurrency, aside from possibly Rust. Erlang is fantastic, but not imperative. D
  - hazz99 8y ago
    Doesn't D just have message passing & mutexes? Which is fine, since D is supposed to be a better C. I wouldn't consider its concurrent primitives comparable to Ada. This is to be expected, since I don't believe they aim for such a nuanced level of concurrency. The Ada runtime is incredibly huge and complex - it was created by the US military, after all.
marcosdumay 8y ago
One of the talking points of Rust is fearless concurrency. Concurrency in Rust is not difficult (neither complex nor error-prone), but you have some high-level primitives that you must know how to choose and use.

jchw 8y ago

I hope Rust or Rust-like languages make it into the kernel, but I think it's worth noting that a huge problem right now is the toolchain and its dependencies. Go may have a better story here though I wouldn't bet on it being a more likely choice for kernel mode.

wmf 8y ago
What is the problem with the Rust toolchain?
- eftychis 8y ago
  Same question: I am not sure go has solved the dependency problem at all.
  - jchw 8y ago
    When I said dependencies, I was not referring to dependency management. I was referring to the footprint of the toolchain. I'll reply to parent on what I meant in more detail, though.
    - eftychis 8y ago
      Ok! I see. Yes that is true. Thanks for the clarification.
- jchw 8y ago
  Nothing at all, really, but kernel developers are going to be picky. For example, does LLVM target all of the architectures Linux supports today? Also, I think it's hard to sell Rust as a hard dependency of the Linux kernel when it isn't nearly as widespread as almost every other kernel dependency. I also sorta remember some kernel developers (not necessarily Linux) making a fuss about rustc using a huge amount of address space and not working on 32-bit systems for that reason - although frankly, I can't remember where I read that and I'm starting to question how much I'm misremembering there.