6 ms·

I wonder if Haiku could become the foundation for a new os. Haiku but based on Rust. It would be a match made in heaven, Haiku's secret sauce is the asyncness o

I wonder if Haiku could become the foundation for a new os. Haiku but based on Rust. It would be a match made in heaven, Haiku's secret sauce is the asyncness of the API. This was doable in C++ however Rust and haiku are a wombo combo!

drb91 8y ago
You’re basically describing Fuschia. I believe they have some of the main haiku kernel (probably a bad description) developers.
- adamnemecek 8y ago
  What language is the fuchsia api in?
  - drb91 8y ago
    IIRC there are native rust bindings for syscalls. The syscalls themselves are implemented in C++. I have no idea about the user space, but my impression is that rust is a first level language for things like the ui. EDIT: it looks like they have interface generators for their APIs, which includes rust support as a first class citizen.
- Apocryphon 8y ago
  I've always wondered what BeOS would look like as a smartphone platform. Even from a UX standpoint, similar to the Windows 95 Mobile concept video.
  - chipotle_coyote 8y ago
    It would have looked a lot like PalmOS 6, a/k/a PalmOS Cobalt. Palm bought Be's assets -- and many of their engineers -- when the company failed, and built their next generation PalmOS around it. For reasons as much due to internal politics as anything technical, though, they never shipped any Cobalt-based phones.
- return_0e 8y ago
  Well Zircon (Fuchsia's kernel) doesn't have any Rust code inside of it; it's C++. Parts of rust code used in Fuchsia can be found in the Garnet layer and it is just one of the languages that can interface with the OS via the FIDL (Fuchsia Interface Definition Language) [0][1]. An example of this is a tool written in Rust that communicates with parts of the bluetooth stack[2]. The network stack is also using it and is written in Go. [3] [0] https://github.com/fuchsia-mirror/zircon/tree/master/system/host/fidl https://github.com/fuchsia-mirror/zircon/tree/master/system/... [1] https://github.com/fuchsia-mirror/zircon/blob/master/docs/fidl/index.md https://github.com/fuchsia-mirror/zircon/blob/master/docs/fi... [2] https://github.com/fuchsia-mirror/garnet/tree/master/bin/bluetooth https://github.com/fuchsia-mirror/garnet/tree/master/bin/blu... [3] https://github.com/fuchsia-mirror/garnet/tree/master/go/src/netstack https://github.com/fuchsia-mirror/garnet/tree/master/go/src/...
- captainmuon 8y ago
  From the technical side, maybe. From the user side they could not be more different. BeOS was the ultimate power user OS. You had a lot of power, but also responsibility. It included many features like the novel filesystem that more pragmatic OSes didn't include. Fuchsia, as far as I can see, is the ultimate "modern" OS. While very safe, it will be very locked down, in the tradition of iOS, Android, Secure Boot, HTML5+js etc. but "done right". There will probably be a lot of things I won't be able to do with a Fuchsia phone.
  - solarkraft 8y ago
    I'm very happy Fuchsia is open source, so forks & custom ROMs will still exist.
    - greenhouse_gas 8y ago
      Are you sure? While its open source, your phone won't be (since the OS is MIT licensed, your OEM won't have to give you anything). Can you build a custom ROM without kernel sources?
      - thelastidiot 8y ago
        I appreciate what you are saying. So many people assume that open source gives them the keys of the castle, while later they realize that a simple broadcom closed source driver puts the whole openess in the trash.
      - drb91 8y ago
        This doesn’t seem to have anything to do with the software, though. You can easily lock down linux for a given phone if that’s your goal (at face value anyway).
        e12e 8y ago
        Well, this is the reason the gpl v3 came about - to ensure the four freedoms even when faced with "trusted computing".
- tormeh 8y ago
  How does Fuchsia compare to Redox? The PL nerd in me is thinking: "Written in C++. Lame." Of course, that attitude didn't work out very well for the iPod guy.
  - drb91 8y ago
    They seem fundamentally different. Fuschia is realtime and, I think, engineered toward embedded and mobile at the moment. Redox is more about cleaning up unix (that’s my impression, anyway). If you squint, it’s like qnx vs linux/bsd, I guess.
    - vitno 8y ago
      Fuchsia is not realtime.
      - drb91 8y ago
        You’re right, I think I was conflating concepts here. My bad. I would edit if I could.
- mtgx 8y ago
  Does Fuchsia use Rust at all? Because if not, it should. It seems like a wasted opportunity not to preempt tens of thousands of future memory corruption bugs over the next few days for a brand new OS by not using Rust.
dnautics 8y ago
Having programmed in the BeOS API long ago, and now a BEAM language developer, I noticed that basically they were implementing a crude and unsafe actor model. There must be modern libraries that provide that at a lower level than say the erlang VM, but with better safety guarantees than C++.
- tormeh 8y ago
  Actix[0] is probably what you're looking for. I don't think the actors in Actix are network transparent, though, which is a bummer for distributed applications, but wouldn't matter for an OS. 0: https://actix.rs/ https://actix.rs/
- losvedir 8y ago
  I think a lower level, type safe, actor based framework is the idea behind the Pony language, which I've been meaning to check out.
  - krylon 8y ago
    I played around with Pony a little, and I found the library situation unsatisfactory. But the type system is gorgeous. And the community is awesome.
  - dnautics 8y ago
    Obsessive type safety in my opinion is a bit silly, it stems from this thought that you can squeeze out every possible runtime error by defensively coding. The truth is, you can't; there are going to be language errors, os errors, driver errors, and errant cosmic rays. Designing for resilience is not solved by typing, and an obsessive typing pattern can create a false sense of security.
    - OtterCoder 8y ago
      Bah, I've seen runtime errors with dynamic and strict typing, and I'll take type safety any day. Besides, good type systems like Rust's force you to think about all sorts of errors at all points of the program. It's harder to write, but it's harder to break, and much, much easier to fix.
Thaxll 8y ago
I think at the OS level, safety from Rust are less useful. The "wrap unsafe code" doesn't really work.
- steveklabnik 8y ago
  Have you tried it? My experience is that it works pretty well, though I've mostly been working on toys. Even bigger projects like Redox have shown that you generally don't need very much unsafe.
- blintzing 8y ago
  There’s a nice Stanford class I took called CS 140E that had students write an OS for the Raspeberry Pi in Rust. There are actually some benefits to using Rust at this level, though it can be a bit cumbersome at times. Check it out here: https://web.stanford.edu/class/cs140e/ https://web.stanford.edu/class/cs140e/
  - pieterr 8y ago
    Interesting! One of the instructors is RocketMan. :-) https://crates.io/crates/rocket https://crates.io/crates/rocket
- TomMarius 8y ago
  What do you mean, doesn't really work? In my experience, it works perfectly. Could you share more info?
- leshow 8y ago
  If you've written any amount of Rust then that's provably not true. You've no doubt used functions & methods that use unsafe (somewhere down along the line), and you didn't need to deal with it. That's 'wrapping unsafe code' used in practice. You got to write safe because someone else wrote the unsafe wrapper.

drb91 8y ago

You’re basically describing Fuschia. I believe they have some of the main haiku kernel (probably a bad description) developers.

adamnemecek 8y ago
What language is the fuchsia api in?
- drb91 8y ago
  IIRC there are native rust bindings for syscalls. The syscalls themselves are implemented in C++. I have no idea about the user space, but my impression is that rust is a first level language for things like the ui. EDIT: it looks like they have interface generators for their APIs, which includes rust support as a first class citizen.
Apocryphon 8y ago
I've always wondered what BeOS would look like as a smartphone platform. Even from a UX standpoint, similar to the Windows 95 Mobile concept video.
- chipotle_coyote 8y ago
  It would have looked a lot like PalmOS 6, a/k/a PalmOS Cobalt. Palm bought Be's assets -- and many of their engineers -- when the company failed, and built their next generation PalmOS around it. For reasons as much due to internal politics as anything technical, though, they never shipped any Cobalt-based phones.
return_0e 8y ago
Well Zircon (Fuchsia's kernel) doesn't have any Rust code inside of it; it's C++. Parts of rust code used in Fuchsia can be found in the Garnet layer and it is just one of the languages that can interface with the OS via the FIDL (Fuchsia Interface Definition Language) [0][1]. An example of this is a tool written in Rust that communicates with parts of the bluetooth stack[2]. The network stack is also using it and is written in Go. [3] [0] https://github.com/fuchsia-mirror/zircon/tree/master/system/host/fidl https://github.com/fuchsia-mirror/zircon/tree/master/system/... [1] https://github.com/fuchsia-mirror/zircon/blob/master/docs/fidl/index.md https://github.com/fuchsia-mirror/zircon/blob/master/docs/fi... [2] https://github.com/fuchsia-mirror/garnet/tree/master/bin/bluetooth https://github.com/fuchsia-mirror/garnet/tree/master/bin/blu... [3] https://github.com/fuchsia-mirror/garnet/tree/master/go/src/netstack https://github.com/fuchsia-mirror/garnet/tree/master/go/src/...
captainmuon 8y ago
From the technical side, maybe. From the user side they could not be more different. BeOS was the ultimate power user OS. You had a lot of power, but also responsibility. It included many features like the novel filesystem that more pragmatic OSes didn't include. Fuchsia, as far as I can see, is the ultimate "modern" OS. While very safe, it will be very locked down, in the tradition of iOS, Android, Secure Boot, HTML5+js etc. but "done right". There will probably be a lot of things I won't be able to do with a Fuchsia phone.
- solarkraft 8y ago
  I'm very happy Fuchsia is open source, so forks & custom ROMs will still exist.
  - greenhouse_gas 8y ago
    Are you sure? While its open source, your phone won't be (since the OS is MIT licensed, your OEM won't have to give you anything). Can you build a custom ROM without kernel sources?
    - thelastidiot 8y ago
      I appreciate what you are saying. So many people assume that open source gives them the keys of the castle, while later they realize that a simple broadcom closed source driver puts the whole openess in the trash.
    - drb91 8y ago
      This doesn’t seem to have anything to do with the software, though. You can easily lock down linux for a given phone if that’s your goal (at face value anyway).
      - e12e 8y ago
        Well, this is the reason the gpl v3 came about - to ensure the four freedoms even when faced with "trusted computing".
tormeh 8y ago
How does Fuchsia compare to Redox? The PL nerd in me is thinking: "Written in C++. Lame." Of course, that attitude didn't work out very well for the iPod guy.
- drb91 8y ago
  They seem fundamentally different. Fuschia is realtime and, I think, engineered toward embedded and mobile at the moment. Redox is more about cleaning up unix (that’s my impression, anyway). If you squint, it’s like qnx vs linux/bsd, I guess.
  - vitno 8y ago
    Fuchsia is not realtime.
    - drb91 8y ago
      You’re right, I think I was conflating concepts here. My bad. I would edit if I could.
mtgx 8y ago
Does Fuchsia use Rust at all? Because if not, it should. It seems like a wasted opportunity not to preempt tens of thousands of future memory corruption bugs over the next few days for a brand new OS by not using Rust.

dnautics 8y ago

Having programmed in the BeOS API long ago, and now a BEAM language developer, I noticed that basically they were implementing a crude and unsafe actor model. There must be modern libraries that provide that at a lower level than say the erlang VM, but with better safety guarantees than C++.

tormeh 8y ago
Actix[0] is probably what you're looking for. I don't think the actors in Actix are network transparent, though, which is a bummer for distributed applications, but wouldn't matter for an OS. 0: https://actix.rs/ https://actix.rs/
losvedir 8y ago
I think a lower level, type safe, actor based framework is the idea behind the Pony language, which I've been meaning to check out.
- krylon 8y ago
  I played around with Pony a little, and I found the library situation unsatisfactory. But the type system is gorgeous. And the community is awesome.
- dnautics 8y ago
  Obsessive type safety in my opinion is a bit silly, it stems from this thought that you can squeeze out every possible runtime error by defensively coding. The truth is, you can't; there are going to be language errors, os errors, driver errors, and errant cosmic rays. Designing for resilience is not solved by typing, and an obsessive typing pattern can create a false sense of security.
  - OtterCoder 8y ago
    Bah, I've seen runtime errors with dynamic and strict typing, and I'll take type safety any day. Besides, good type systems like Rust's force you to think about all sorts of errors at all points of the program. It's harder to write, but it's harder to break, and much, much easier to fix.

Thaxll 8y ago

I think at the OS level, safety from Rust are less useful. The "wrap unsafe code" doesn't really work.

steveklabnik 8y ago
Have you tried it? My experience is that it works pretty well, though I've mostly been working on toys. Even bigger projects like Redox have shown that you generally don't need very much unsafe.
blintzing 8y ago
There’s a nice Stanford class I took called CS 140E that had students write an OS for the Raspeberry Pi in Rust. There are actually some benefits to using Rust at this level, though it can be a bit cumbersome at times. Check it out here: https://web.stanford.edu/class/cs140e/ https://web.stanford.edu/class/cs140e/
- pieterr 8y ago
  Interesting! One of the instructors is RocketMan. :-) https://crates.io/crates/rocket https://crates.io/crates/rocket
TomMarius 8y ago
What do you mean, doesn't really work? In my experience, it works perfectly. Could you share more info?
leshow 8y ago
If you've written any amount of Rust then that's provably not true. You've no doubt used functions & methods that use unsafe (somewhere down along the line), and you didn't need to deal with it. That's 'wrapping unsafe code' used in practice. You got to write safe because someone else wrote the unsafe wrapper.