[tmhedberg]

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.

[mokus]

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]

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.

[regularfry]

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