Running Rust on the Rumprun Unikernel (opens in new tab)

(gandro.github.io)

155 pointsdoublextremevil10y ago17 comments

17 comments

16 comments · 6 top-level

sgt10y ago· 4 in thread

Speaking of Rust - is anyone running Rust in production apps yet? Now that Rust has reached 1.3.0, it's perhaps not unlikely.

icebraining10y ago

https://doc.rust-lang.org/complement-lang-faq.html#is-anyone...?

cpach10y ago

Clickable link :-p

https://doc.rust-lang.org/complement-lang-faq.html#is-anyone...

steveklabnik10y ago

We did an interview with our production users a few months back: https://internals.rust-lang.org/t/production-user-research-s...

Names you might have heard of: Dropbox, Skylight.io, Sandstorm.io, Tessel, Terminal.com, Chef, among others.

listic10y ago

Thanks! Could you possibly please update the FAQ with all the recent users?

1 more reply

kctess510y ago· 3 in thread

What kind of embedded devices could this be booted with?

gandro10y ago

Rumprun doesn't require (or support) virtual memory, so granted enough memory (a few megabytes), it can work on embedded systems.

Rumprun currently runs on x86 and x86-64, support for RISC-V and ARM is in the making. The architecture specific code is quite small, you just need to make sure that NetBSD (and Rust) support your architecture as well.

conceit10y ago

Anything that can run FreeBSD and then some? I don't know.

4ad10y ago

NetBSD, not FreeBSD.

hacknat10y ago· 2 in thread

Well done!

It'll be interesting to see what space unikernels take up in the coming years.

I think there is still a lot of fruitful territory to be explored in this space as traditional multi-user, multi-tenant assumptions can be thrown out the window. I think a big, unexplored advance that unikernels might be able to offer is the ability for the kernel-part to peek into the guts of what its programs are actually doing (at compile or run time) and make broader assumptions about scheduling.

vezzy-fnord10y ago

It would probably be the other way around, the programs making their own fine-grained policies from primitive kernel mechanisms. This has been an area of research for decades.

Multi-tenant assumptions probably aren't going away, since mainstream systems have by and large not been able to handle them.

hacknat10y ago

In this case I meant that something of a runtime or additional code could be tacked on to programs when the compiler and/or run time sees that a program only computes in response to input, for example. In the case of unikernels, distinguishing parts of the "system" is an arbitrary line.

4ad10y ago· 1 in thread

I would like to hear more about what things are unsupported. For example, rump kernels do not have fork, so obviously if you expect you application to fork, it will not work. But there are other, more subtle caveats.

anttiok10y ago

Your statement "rump kernels do not have fork" is not entirely accurate in the context. Rump kernels do support fork. However, it is not conceptually a rump kernel's business to provide fork. So it's actually the Rumprun unikernel that does not provide fork here. It's a small but quite important distinction, because it means that if you wanted, you could take the upper part of the stack and bolt it on to some other simple bottom layer which does support fork. I certainly don't want to, but maybe someone else does.

Anyway, you are right, not everything is supported. It would be cool to know if a valid program will work on Rust+Rumprun without having to run it, but I can't imagine a simple solution to that problem. I guess if the problem of knowing if something will work without running it were solved, programs wouldn't have bugs ;)

doomrobo10y ago

Great work! I'm so glad this has been done. I think seeing OCaml used with Xen made me realize how great Rust could be in this context.

softprodigy10y ago

Great news!

j / k navigate · click thread line to collapse