Hacker News Reader

Comment by adamnemecek | Hacker News Reader

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!

View on HN

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++.

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/

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.

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.

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.

have you ever programmed in a BEAM language like erlang or elixir? It's easy to write, when there are errors, most of the time it's "no big deal". If something that is outside of your control (someone else's code, or hardware, or a driver, etc) then it's often not a fatal problem. Pushing errors to the edge is great, but "forcing you to think about all sorts of errors", I think is an antipattern. You should code the happy path, anticipate the 80% errors, patch the next 19% error, and ignore the last tiny sliver of errors, and generally be able to refactor easily.

Of course your environment should be able to survive and persist 99.99999% of errors, that's critical... there should be no throw()s or panic()s.

No, and I really should give those a try. That said, when I just want happy-path, idc, just reload on errors, kind of code, it's a sore temptation to just reach for JS.

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.

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

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/...

[1] https://github.com/fuchsia-mirror/zircon/blob/master/docs/fi...

[2] https://github.com/fuchsia-mirror/garnet/tree/master/bin/blu...

[3] https://github.com/fuchsia-mirror/garnet/tree/master/go/src/...

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.

I'm very happy Fuchsia is open source, so forks & custom ROMs will still exist.

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?

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).

Well, this is the reason the gpl v3 came about - to ensure the four freedoms even when faced with "trusted computing".

Unfortunately Torvalds rejected migrating to it, and seems to be quite an outspoken critic against the GPLv3

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.

I've been happily buying Nexus and Pixel phones for as long as they've existed, on which you can easily unlock the bootloader and build your own ROM if you want. I don't see why Google would stop doing that just because they've released a new OS.

If you're concerned about installing your own software on your own hardware, why not buy it from a manufacturer that protects your freedom to be able to do so?

Well for starters they have been cleaning up Android from GPL related licenses.

Android now compiles with clang, including their own modified Linux kernel, and gcc is no longer supported on the NDK.

Yes, but they are still shipping AOSP and still selling Pixel phones with unlockable bootloaders.

Clearly, Google wants to be able to support companies which want to sell locked-down phones.

But as long as they sell their own phones with unlockable bootloaders, you can vote with your wallet and buy those phones.

I am concerned about the reduction in use of the GPL, but what I care about is being able to run and modify the software on my phone, and as long as Google is still releasing AOSP (and the Fuchsia open source project), and selling phones that are unlocked, I'm happy enough with that.

Yes, they might change their policy in the future. But for now there's no indication that they intend to do that; they've always been good at selling their own phones and Pixelbooks with unlockable bootloaders that does allow you to replace the ROM if you want.

I (not having looked at the architecture yet) have a suspicion that Fuchsia will run on a hardware-independent layer, like Treble which they're pushing right now.

HTML5+js is very locked down?

Maybe in the sense that webpages cannot talk to each other directly.

or the hardware

Yes, think of ChromeOS.

You are locked to the browser sandbox and web sites, which you will never see the code running on their servers.

X11 terminals are back, just prettier.

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.

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.

Fuchsia is not realtime.

You’re right, I think I was conflating concepts here. My bad. I would edit if I could.

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.

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.

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.

What language is the fuchsia api in?

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.

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

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/

Interesting! One of the instructors is RocketMan. :-)

https://crates.io/crates/rocket

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.

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.

What do you mean, doesn't really work? In my experience, it works perfectly. Could you share more info?

Reply on news.ycombinator.com