16 ms·

Operating System Development in Rust

160 points by krenoten 12y ago

krenoten 12y ago
Many people seem to be confused by Rust's lack of limitations imposed on you as a programmer. In particular, the fact that so much of what is thought of as a runtime is provided as optional libraries. You can run tasks similar to Goroutines, which are provided as a library. You can use certain types of garbage collection as a library. You have dramatic freedom and accessible choices. The possibilities are incredibly inspiring.
- SwellJoe 12y ago
  In my tinkering with both Go and Rust, and liking the looks of both, I get vague feelings like Go is to Python as Rust is to Perl. This may be damning praise for some folks, but it makes me lean slightly toward Rust more than Go (slightly). There seems to be almost an anti-library culture in Go (i.e. "use the standard library" is almost a mantra in Go) whereas in Rust, there's more than one way to do it (even this early in its existence). That said, in many ways neither language is like the one I've compared it to, probably in enough ways that it's not a useful comparison for much other than this one metric (the TIMTOWDIness of the language). But, it's how my head is processing these two quite novel (to me) languages; which would make sense, as I've written more code in Python and Perl than probably anything else, so they're the known things I compare these unknown things to.
  - thirsteh 12y ago
    You could say that Go is Python and Rust is Haskell, because, well, Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers.
    - vezzy-fnord 12y ago
      Could you elaborate on that? Rust has a powerful static type system, HOFs, is expression-based, has an unusually good pattern matching engine for its intended area, assumes immutability by default and uses a notation for function signatures typically associated with FP, but I don't think those are enough to call it a "cleverly disguised Haskell". In fact, it has been my observation that the language has been getting progressively less functional since its early days. Not that I consider this to be bad.
      - thirsteh 12y ago
        Sure -- basically what you said: http://science.raphael.poss.name/rust-for-functional-programmers.html#straightforward-equivalences http://science.raphael.poss.name/rust-for-functional-program... Of course it's not exactly Haskell, but it's arguably closer to FP than it is to C, yet manages to be approachable to imperative programmers. I think this is fantastic.
        nightski 12y ago
        That would be a really tough argument to make. It goes to great lengths to give control over memory layout and control and lacks a LOT of the features of Haskell's type system. It's a lot more like a prettier D than Haskell. Not only that with every iteration it has been moving farther away from the FP paradigm.
        naasking 12y ago
        I think you mean GHC's type system, since Rust is arguably quite close to Haskell 98 in spirit, ie. algebraic types, lambdas, pattern matching, traits = single parameter type classes.
      - Retra 12y ago
        I think the point is that it seems actively inspired by Haskell -- that the things people like about Haskell are the same things the designers of Rust want in their language.
    - agumonkey 12y ago
      Reminds me of hop and house (haskell based OS) http://lambda-the-ultimate.org/node/299 http://lambda-the-ultimate.org/node/299 ~ 2004
    - detrino 12y ago
      > Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers. This comment is very condescending. It makes it seem as if C programmers are ignorant and Haskell programmers are enlightened. Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in. These are also qualities not shared by Rust, which may explain why there is less resistance in its uptake by C programmers.
      - thirsteh 12y ago
        Oh, come on. Don't take things so seriously. There are tons of Haskell programmers who don't know C, too, and Rust is just as much of a way for them to reap the benefits of C as it is anything else.
      - naasking 12y ago
        > Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in. Don't be so sure! [1] You could simply use Haskell as a metalanguage to generate a C program that does what you need, just like they did with copilot. No Haskell runtime needed. [1] https://github.com/leepike/copilot-discussion https://github.com/leepike/copilot-discussion
    - kyllo 12y ago
      I'd say Rust is more like C and OCaml had a baby.
      - saosebastiao 12y ago
        An amazing compliment, IMO.
- tuxychandru 12y ago
  Which library provides goroutine like concurrency in rust?
  - krenoten 12y ago
    With 1.0, rust no longer has a runtime at all, so official support for libgreen was actually dropped. However, between sync::mpsc, sync::TaskPool and sync::Future you can produce similar results.
    - tuxychandru 12y ago
      All those deal with threads. Rust 1.0 will have multi-threading just like C++, Java, etc. It is very different from how Goroutines work and do not offer similar benefits at all (specifically for network services). libgreen while it existed scaled very poorly and consensus among rust developers seemed to be that, it cannot be improved without compromising some of the core features of rust like no-GC and zero-overhead calls to C libraries.
      - krenoten 12y ago
        Even with Go it's a fairly bad idea not to use Goroutine pools for request handling if you're writing low-latency services. You can get isomorphic results with a future pool and channels.
        tuxychandru 12y ago
        It is not about whether goroutines need to be pooled. Goroutines work very differently from how OS threads. They are scheduled at the user-level by using non-blocking system calls to perform network IO on multiple OS threads. They are also partially pre-empted on function calls. Whether goroutines need to be pooled depends on the application. For example, the default HTTP creates ones per connection and seems to be used without any problem in production at a lot of places. Creating them is much cheaper than creating OS threads. In fact, libgreen threads were faster to spawn than libnative ones in rust when it existed. Rust and Go have different trade-offs when it comes to concurrency and each has its benefits and drawbacks.
- vegedor 12y ago
  >Many people seem to be confused by Rust's lack of limitations imposed That sounds ridiculously like PR-speak. Without the double negative the only information I get is, people are confused by the possibilities, that are however not unlimited - which isn't very surprising for people new to the language.
thom 12y ago
Also worth checking out: http://rust-class.org/ http://rust-class.org/ Or maybe this, if UEFI is palatable to you: http://blog.theincredibleholk.org/blog/2013/11/18/booting-to-rust/ http://blog.theincredibleholk.org/blog/2013/11/18/booting-to...
Animats 12y ago
Somewhere in this direction lies the post-C era. The post-buffer-overflow era. And do we need it. It has been 6 days since the last CERT advisory for a buffer overflow security hole.
- userbinator 12y ago
  The era of unrootable devices, unbreakable DRM, and inescapable walled gardens? Considering that this will basically be "trusted computing done right", I'm quite frankly more scared than anything... I'm not saying that security holes are nothing to worry about, as I am no less irritated by buggy programs than anyone else, but the alternative might be worse.
  - tatterdemalion 12y ago
    Restrictions placed on Turing machines by their producers are ultimately a political problem and not a technical one. We will indeed have to solve it one day once those restrictions are not buggy.
    - userbinator 12y ago
      It is a political problem, but I think it's one that has to be solved very very soon, because the majority of the population seem to acquiesce quickly to these new restrictions and "safer" (against them) systems without thinking much of the negative aspects. To let it reach the point when freedom is completely associated with malware, terrorism, or whatever else is used to frighten the population into comformity, it may be too late to oppose.
    - randallsquared 12y ago
      In general, technical problems can be permanently solved, and political problems cannot be. Where possible, it's always preferable to turn a political problem into a technical problem.
  - krenoten 12y ago
    We are past the point where exploits are a cheap, democratic weapon. So it's time to close the holes that governments and organized crime are using against us. It's our responsibility to build systems that provide democratizing power. It's also our responsibility to practice exercising our political power. Politics will be important for however long we are human.
cmsd2 12y ago
For bootstrapping a kernel, I had trouble with cross compiling. My kernel doesn't yet support a libc hosted environment, so I use a i686-pc-elf gcc target with -ffreestanding. rustc works niceley if your target environment is similar enough to your dev environment, or if you are developing for android for which there's an sdk and rustc port already. I initially tripped up on this because i'm developing on osx currently, but targetting gnu. I just need the rustc equivalent of -ffreestanding. Alternatively I'll have to wait until I've got a proper i686-myos gcc and libc port.

160 points by krenoten 12y ago

Many people seem to be confused by Rust's lack of limitations imposed on you as a programmer. In particular, the fact that so much of what is thought of as a runtime is provided as optional libraries. You can run tasks similar to Goroutines, which are provided as a library. You can use certain types of garbage collection as a library. You have dramatic freedom and accessible choices. The possibilities are incredibly inspiring.

SwellJoe 12y ago
In my tinkering with both Go and Rust, and liking the looks of both, I get vague feelings like Go is to Python as Rust is to Perl. This may be damning praise for some folks, but it makes me lean slightly toward Rust more than Go (slightly). There seems to be almost an anti-library culture in Go (i.e. "use the standard library" is almost a mantra in Go) whereas in Rust, there's more than one way to do it (even this early in its existence). That said, in many ways neither language is like the one I've compared it to, probably in enough ways that it's not a useful comparison for much other than this one metric (the TIMTOWDIness of the language). But, it's how my head is processing these two quite novel (to me) languages; which would make sense, as I've written more code in Python and Perl than probably anything else, so they're the known things I compare these unknown things to.
- thirsteh 12y ago
  You could say that Go is Python and Rust is Haskell, because, well, Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers.
  - vezzy-fnord 12y ago
    Could you elaborate on that? Rust has a powerful static type system, HOFs, is expression-based, has an unusually good pattern matching engine for its intended area, assumes immutability by default and uses a notation for function signatures typically associated with FP, but I don't think those are enough to call it a "cleverly disguised Haskell". In fact, it has been my observation that the language has been getting progressively less functional since its early days. Not that I consider this to be bad.
    - thirsteh 12y ago
      Sure -- basically what you said: http://science.raphael.poss.name/rust-for-functional-programmers.html#straightforward-equivalences http://science.raphael.poss.name/rust-for-functional-program... Of course it's not exactly Haskell, but it's arguably closer to FP than it is to C, yet manages to be approachable to imperative programmers. I think this is fantastic.
      - nightski 12y ago
        That would be a really tough argument to make. It goes to great lengths to give control over memory layout and control and lacks a LOT of the features of Haskell's type system. It's a lot more like a prettier D than Haskell. Not only that with every iteration it has been moving farther away from the FP paradigm.
        naasking 12y ago
        I think you mean GHC's type system, since Rust is arguably quite close to Haskell 98 in spirit, ie. algebraic types, lambdas, pattern matching, traits = single parameter type classes.
    - Retra 12y ago
      I think the point is that it seems actively inspired by Haskell -- that the things people like about Haskell are the same things the designers of Rust want in their language.
  - agumonkey 12y ago
    Reminds me of hop and house (haskell based OS) http://lambda-the-ultimate.org/node/299 http://lambda-the-ultimate.org/node/299 ~ 2004
  - detrino 12y ago
    > Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers. This comment is very condescending. It makes it seem as if C programmers are ignorant and Haskell programmers are enlightened. Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in. These are also qualities not shared by Rust, which may explain why there is less resistance in its uptake by C programmers.
    - thirsteh 12y ago
      Oh, come on. Don't take things so seriously. There are tons of Haskell programmers who don't know C, too, and Rust is just as much of a way for them to reap the benefits of C as it is anything else.
    - naasking 12y ago
      > Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in. Don't be so sure! [1] You could simply use Haskell as a metalanguage to generate a C program that does what you need, just like they did with copilot. No Haskell runtime needed. [1] https://github.com/leepike/copilot-discussion https://github.com/leepike/copilot-discussion
  - kyllo 12y ago
    I'd say Rust is more like C and OCaml had a baby.
    - saosebastiao 12y ago
      An amazing compliment, IMO.
tuxychandru 12y ago
Which library provides goroutine like concurrency in rust?
- krenoten 12y ago
  With 1.0, rust no longer has a runtime at all, so official support for libgreen was actually dropped. However, between sync::mpsc, sync::TaskPool and sync::Future you can produce similar results.
  - tuxychandru 12y ago
    All those deal with threads. Rust 1.0 will have multi-threading just like C++, Java, etc. It is very different from how Goroutines work and do not offer similar benefits at all (specifically for network services). libgreen while it existed scaled very poorly and consensus among rust developers seemed to be that, it cannot be improved without compromising some of the core features of rust like no-GC and zero-overhead calls to C libraries.
    - krenoten 12y ago
      Even with Go it's a fairly bad idea not to use Goroutine pools for request handling if you're writing low-latency services. You can get isomorphic results with a future pool and channels.
      - tuxychandru 12y ago
        It is not about whether goroutines need to be pooled. Goroutines work very differently from how OS threads. They are scheduled at the user-level by using non-blocking system calls to perform network IO on multiple OS threads. They are also partially pre-empted on function calls. Whether goroutines need to be pooled depends on the application. For example, the default HTTP creates ones per connection and seems to be used without any problem in production at a lot of places. Creating them is much cheaper than creating OS threads. In fact, libgreen threads were faster to spawn than libnative ones in rust when it existed. Rust and Go have different trade-offs when it comes to concurrency and each has its benefits and drawbacks.
vegedor 12y ago
>Many people seem to be confused by Rust's lack of limitations imposed That sounds ridiculously like PR-speak. Without the double negative the only information I get is, people are confused by the possibilities, that are however not unlimited - which isn't very surprising for people new to the language.

thom 12y ago

Also worth checking out: http://rust-class.org/ http://rust-class.org/ Or maybe this, if UEFI is palatable to you: http://blog.theincredibleholk.org/blog/2013/11/18/booting-to-rust/ http://blog.theincredibleholk.org/blog/2013/11/18/booting-to...

Animats 12y ago

Somewhere in this direction lies the post-C era. The post-buffer-overflow era. And do we need it. It has been 6 days since the last CERT advisory for a buffer overflow security hole.

userbinator 12y ago
The era of unrootable devices, unbreakable DRM, and inescapable walled gardens? Considering that this will basically be "trusted computing done right", I'm quite frankly more scared than anything... I'm not saying that security holes are nothing to worry about, as I am no less irritated by buggy programs than anyone else, but the alternative might be worse.
- tatterdemalion 12y ago
  Restrictions placed on Turing machines by their producers are ultimately a political problem and not a technical one. We will indeed have to solve it one day once those restrictions are not buggy.
  - userbinator 12y ago
    It is a political problem, but I think it's one that has to be solved very very soon, because the majority of the population seem to acquiesce quickly to these new restrictions and "safer" (against them) systems without thinking much of the negative aspects. To let it reach the point when freedom is completely associated with malware, terrorism, or whatever else is used to frighten the population into comformity, it may be too late to oppose.
  - randallsquared 12y ago
    In general, technical problems can be permanently solved, and political problems cannot be. Where possible, it's always preferable to turn a political problem into a technical problem.
- krenoten 12y ago
  We are past the point where exploits are a cheap, democratic weapon. So it's time to close the holes that governments and organized crime are using against us. It's our responsibility to build systems that provide democratizing power. It's also our responsibility to practice exercising our political power. Politics will be important for however long we are human.

cmsd2 12y ago

For bootstrapping a kernel, I had trouble with cross compiling. My kernel doesn't yet support a libc hosted environment, so I use a i686-pc-elf gcc target with -ffreestanding. rustc works niceley if your target environment is similar enough to your dev environment, or if you are developing for android for which there's an sdk and rustc port already. I initially tripped up on this because i'm developing on osx currently, but targetting gnu. I just need the rustc equivalent of -ffreestanding. Alternatively I'll have to wait until I've got a proper i686-myos gcc and libc port.