7 ms·

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

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.

darkstalker 13y ago
NetBSD supports Lua in the kernel
tmhedberg 13y ago
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.
- regularfry 13y ago
  The Lisp Machines would seem to be the counterpoint to that point of view.
- mokus 13y ago
  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.
  - hderms 13y ago
    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.
astrobe_ 13y ago
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.

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.

darkstalker 13y ago

NetBSD supports Lua in the kernel

tmhedberg 13y ago

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.

regularfry 13y ago
The Lisp Machines would seem to be the counterpoint to that point of view.
mokus 13y ago
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.
- hderms 13y ago
  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.

astrobe_ 13y ago

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.