Is Haskell a Good Choice for Web Applications? (2009) | Hacker News Reader

Is Haskell a Good Choice for Web Applications? (2009)

jekor.com

93 pointsdmitriy_ko21 comments

Please update the title to indicate that this was written in 2009. In the meanwhile, Haskell has gained (besides Happstack) two excellent web frameworks: Snap and Yesod.

One of the points of critique has been addressed now is database access. For instance, Persistent provides type-safe database access:

http://www.yesodweb.com/book/persistent

The author also mentions the problem that exceptions can only be caught in the IO monad. But this has become less of a problem, since more people started using monad transformers (such as ErrorT) to add error handling to their monads. ErrorT allows you to catch exceptions within that monad. For instance, quoting from one of my own projects:

    readEntry :: MonadIO m => Corpus -> String -> ErrorT CorpusError m Text

readEntry is a function that takes a Corpus and a String, and returns Text in a monad of the class MonadIO if the function is successful. Otherwise it reports errors in the form of a CorpusError. You could now, for instance, run this function with runErrorT, and it will return an ordinary Either value in the given monad (Left CorpusError in the case of an error, Right Text when the call is successful).

Also, if you aren't wedded to SQL, Haskell now has acid-state, a memory resident database written in Haskell (formerly happstack-state).

How does a memory resident database satisfy the D in ACID?

Presumably it writes to a transaction log, and is memory-resident in the same sense that Redis is. Which is to say that the dataset is kept entirely in memory, but also has a persistent representation on disk.

IIRC happstack-state has a journaling system. You don't have the state on disk, but you can reconstruct it. you could also journal to a remote machine for a live failover.

As someone who's learning Haskell, I read the post because I'm interested in the language's capabilities in the web arena. But your site itself is brilliant! You are really on to something with vocabulink.com. I've formally studied 10 human languages, of which I can speak/write/read 3 fluently, and have passive understanding of another 2-3. People often ask me how I learn languages, and a good part of my answer is very similar to what you are doing with vocabulink. As you've discovered, the key is to use vivid, even silly, mnemonic devices. Building up a large vocabulary is key to learning a language. Don't waste your money on flashy tools like Rosetta Stone -- they don't work for most people above the age of 8 or 10. Adults learn differently than children.

So if someone out there is looking to learn a foreign language, my recommendation is to combine vocabulink's approach to build up a large vocabulary, and find the best concise grammar available for your target language. If you don't remember grammar fundamentals (e.g., what's a prepositional phrase, direct object, relative pronoun, etc.), then you need to find a good book in your native language to review those concepts.

In any case, cool concept for a web site. Sorry for the off-topic post. Thanks for telling us about your experiences with Haskell. I do think that Haskell web capabilities have come a long way since 2009, particularly Yesod (I'm not familiar with Snap).

How secure are these Haskell web frameworks? (snap, happstack, etc.). Without a django and rails level of exposure, presumably they have quite a few holes still?

I don't know about their maturity, but I think Haskell's type system and purity would help with security.

It doesn't have anything like `eval` and is much less tolerant of weird input by default than dynamically typed languages (at least in my experience). Having no or limited state also helps--bad input and other mistakes tend to be more localized when they can't possibly change anything else in the program.

If you're really crazy about security, then I suspect the Haskell code would also be much easier to analyze and verify.

Also, many underlying components are tested using QuickCheck. QuickCheck allows you to verify that the properties of functions hold under random input.

Of course, since such checking is used when the number of possible inputs is too large to check (or infinite), it is not watertight. But it helps tremendously in uncovering bugs.

Well, one feature that Yesod has really been focused on are type-safe URLs[1]. I imagine this would provide some level of security benefit as the framework knows "Ah, in this GET request we should have a Date, an Integer, a UserID, etc".

The implementation may still have bugs, I suppose, but you can be sure that it's at least being heavily thought about.

I imagine forms may work the same way, though I'm not sure about that.

[1] http://www.yesodweb.com/home/snoyberg/blogs/2011/08/shakespe...

Yesod also has automatic html-escaping of strings, enforced at the type level. You have to explicitly tell it when a value is raw html, to avoid XSS. It also has automatic XSRF prevention.

That's not how security works. FreeBSD has more exposure than OpenBSD, but OpenBSD is more secure. Security isn't a measure of how many people have heard of your project, it is a question of whether or not you have carefully designed your project to be secure. Haskell helps prevent a ton of errors that can cause security holes. On top of that, yesod at least has been very carefully designed to both be secure itself, and to make applications developed in yesod be secure by default.

Security holes don't just magically go away when software gets popular. You should be striving to not create security holes in the first place.

But without extensive testing, which popularity generates, it is hard to have confidence that the striving was successful. In other words, popularity narrows the confidence interval around the measured and reported level of security.

Except that popularity doesn't generate extensive testing. IE was one of the most insecure pieces of software ever created, and was incredibly popular. People using software don't find security holes, people looking for security holes do. Has anyone with any credibility done an extensive security audit of ruby on rails? Not that I am aware of. So that puts it at the same level of confidence as snap or yesod. So then we have to judge by things like the track record, the underlying design, and the confidence we have in the developers behind the projects. None of those things are in rails or django's favor.

I've been wondering how well-suited FRP (implemented either in Haskell or something else) is for back-end technology. It seems like it might be overkill, but it does have a certain conceptual elegance to it.

Anyone play around with this idea?

Check out elm: http://elm-lang.org/Elm.elm

Recent reddit conversation: http://www.reddit.com/r/haskell/comments/mwbvj/elm_functiona...

the source link[1] doesn't work for me. anyone know where i can find this document?

[1] http://jekor.com/vocabulink/vocabulink.pdf

It worked here, but only when I did a right-click and "save as".

Reply on news.ycombinator.com