Hacker News Reader

Comment by dkhenry | Hacker News Reader

I am no language designer, but I wonder why use libuv and have to worry about implementing a scheduler and all the other components of a run time loop in your language when the kernel will do this for you. I think it would make more sense to provide a better interface to existing kernel structures then leverage a third party library and then re implement kernel functions around it ( I am mainly thinking about the paragraph about the current scheduler implementation and how basic it is )

View on HN

Three reasons. First, we don't control the kernel and we don't want to make assumptions about thread spawning being cheap on every OS. Second, it lets us implement work stealing, which is a proven method for dynamic parallelism. Third, it lets us do some operations such as RPC from task to task entirely in userspace with no trip through the scheduler or OS kernel.

Good points. A counterpoint for #3 is that you could do kernel bypass RPC by installing a driver, but Rust developers probably don't want to write all those drivers, and Rust users wouldn't want to install them.

Work (task) stealing is very compelling, and a little paradigm shift is no bad thing. If Rust or any new systems language stands a chance, it should aim high and not too close to the past.

And then drivers would be required for each OS creating an additional porting burden.

What if someone wants to write a kernel with Rust? This might be a very naive question taking into account my ignorance of language and kernel design.

I've done some very preliminary (and bumbling) work with that at https://github.com/ldunn/kern/

It's rudimentary, but it does compile and it does run, and I'm not aware of any particular obstacles to a more featureful kernel.

Look at https://github.com/pcwalton/zero.rs . It's not very far yet, but it proves that it is viable to run Rust without a runtime.

I actually don't think we even need zero.rs anymore. Its purpose was to provide noop implementations for all the "lang items" that the compiler expects to find in the stdlib. However, post-0.7 the compiler no longer requires a lang item to be provided unless you actually use a feature that requires it.

For an example, see the code at https://github.com/doublec/rust-from-c-example , which is fully runtimeless.

zero.rs (or something like it) is still required, because there's certain lang items that are required/useful (e.g. #[start], destructors, failure, vector bounds checks).

(e.g. https://github.com/huonw/rust-malloc/blob/master/zero.rs)

Someone posted https://news.ycombinator.com/item?id=5771276 a few months ago. I'm not sure we could call that a kernel, but it's a first step.

Reply on news.ycombinator.com