Hacker News Reader

Comment by ZirconCode | Hacker News Reader

I'm waiting for Ruby. Or JavaScript. It's going to happen some day.

This reminds me a lot of xmonad. I guess higher level languages are migrating downwards to the system level slowly.

It seems like kernel-space code would be one of the worst possible environments in which to use a dynamic language. A runtime error in that context can easily bring down the entire system; you're really better off sticking to languages with at least a semblance of static safety. Haskell may be a high-level language, but it's also a significant improvement over C when it comes to compile-time safety, unlike Ruby and JavaScript, which have none at all.

The Lisp Machines would seem to be the counterpoint to that point of view.

The difference between catching types at runtime or compile time is much less important than the common feature of catching type errors at all. A runtime type error in C simply trashes another subsystem's data. A runtime type error in Python or Ruby is caught, so can theoretically be prevented from cratering the entire system.

Sure, I (as a heavy Haskell user) would rather catch such things at compile time, but given the choice between catching them at runtime and not catching them at all, I'd almost never choose the latter unless there are other overriding concerns.

C compilers catch plenty of type errors. As soon as you start casting things into different types you have the possibility of re-introducing type errors, but presumably you're casting things for a good reason in the first place, and therefore understand the tradeoff.

NetBSD supports Lua in the kernel

It won't because there is next to zero benefit in doing so, while it would have a significant cost. Besides, system programming and application programming are very different domains, that attract very different programmers. Just look at the date on the article, and do a quick search on this topic. You'll see that there is no follow-up.

Reply on news.ycombinator.com