Eric Kidd

Even as someone who knows Haskell, it isn't actually possible to read this article and figure out what specifically about Haskell is helping.

My suspicion is that it is Haskell's great support for domain-specific languages. This is both in the sense of languages that are really "just" Haskell APIs but work in such an different manner that they are quite different, and in the sense of writing a full compiler [1] (or any subset of a compiler) for a new language.

For an example of the former, one of my favorite demonstrations is the "probability monad", in which one ends up with a sort of sublanguage inside of Haskell that is probability aware: http://www.randomhacks.net/2007/02/22/bayes-rule-and-drug-tests/ [2] If you want to start to really grasp the power of Haskell, you could do worse than meditate on how you'd implement that in your $FAVORITE_LANGUAGE... and then, most likely, burst into tears when someone shows you just how much of Haskell still works, unchanged, even in that environment (e.g., everything in Control.Monad), rather than having to be implemented in a parallel type hierarchy (or, put another way, producing a new "color" of functions [3]).

While I doubt they use something exactly like that, it's not hard to see how that sort of thing could make it fairly easy to write spam classification code with a lot of the basic plumbing abstracted away entirely.

There's a lot of examples of the latter, but I'm not sure of a really solid open source example to point…

When I started to learn Lisp, the "Which Lisp?" problem was the first thing to hit me. Same with Scheme. I eventually went with CLISP and PLT (Racket).

Issues like hygiene didn't really bother me too much. As long as you are aware of it its not an issue.

While I really like the power of Lisp/Scheme (especially macros), I find that for most programming task Python or Ruby are good enough. There was an interesting post along similar lines 'Why Ruby is an acceptable Lisp'[1].

One thing I am really interested is in seeing how Perl 6 works out. It supports Lisp style macros (by making the parser available to the programmer) while using conventional syntax. While I am a Python fanboy myself I would seriously consider Perl 6 once there is a CPython grade implementation available.

[1] http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp

> In Haskell, functions do not fail in traditional sense - they just return indication of failure.

That's too general a statement. Haskell functions certainly can fail in the traditional sense. As a trivial example, "head []" is a well-typed Haskell expression that will raise an exception when evaluated; if the exception is not caught (using a traditional exception handler), then it propagates to an error, and the program exits.

This article [1] about the many ways to handle errors in Haskell is a bit old, but as far as I know, all his points are still relevant. The conclusion (for me) is that if modern Haskell tends to use return-values on failure, it's due to convention (and good taste) among developers, and not due to a design constraint of the language.

[1] http://www.randomhacks.net/2007/03/10/haskell-8-ways-to-report-errors/

I love Ruby so much as a scripting language, I ask myself why I don't just use it as an "acceptable lisp" [1] for my research, rather than Haskell. Haskell is more easily parallelized than any other language I've experienced. Alas, my experiments with Ruby 3.1 parallel extensions flunked. Who cares about single core speed?

I was always put off by Rust syntax (it's a fly-pollinated flower, to attract C programmers), but I'm starting to get the genius in its machine model. Learning Rust forces one to understand what's happening at the machine level, but offers better control as a reward. Its expressiveness is a lot closer to Ruby than I had imagined, it won't put me back in the C99 stone ages. So my provisional answer is that Rust is a Faster Ruby.

[1] http://www.randomhacks.net/2005/12/03/why-ruby-is-an-acceptable-lisp/

You can write a kernel in pretty much every language. There are some experiments with Rust: http://www.randomhacks.net/bare-metal-rust/

There are several reasons to choose a language rather than another. I personally don't like Rust at all, so I don't see any reason to use it, neither do I see any advantage in using it. But that's only my opinion. A lot of osdev currently is made by hobbyist (not counting the handful of really succesful kernels), so the main argument is simply personal and there is nothing wrong with it. Moreover, keep in mind that Rust is pretty new while C/C++ are decades old, this means more support, more portability, more people that know how to use it, ... This is not negligible at all.

Standard "canned" reply: Java doesn't force you to annotate exceptions or even to handle them all. Typed returns do. And as to the "where", well, in the originating function.

But that gets us to some real criticism here: You run the danger of getting an Either Monad out of about every function in your code-base... So maybe throwing exceptions isn't the worst thing after all. (/me ducks all the stuff being thrown my way from hardcore [EDIT:] ~Haskell~ functional programming fans :-))

EDIT: s/Haskell/functional programming/
(because its unfair - Haskell can throw stuff: http://www.randomhacks.net/2007/03/10/haskell-8-ways-to-report-errors/)