Hacker News Reader

Comment by the_af | Hacker News Reader

How do you know this Haskell system was "Haskell done right"? I'm not trying to be snarky, this is a genuine question. I have witnessed enough disasters (performance or otherwise) in multiple languages to know not draw conclusions from just one or two failures. Of course, consistent failures by multiple teams do point to a problem with the technology itself.

(Then again, maybe you do have multiple examples and/or have strong evidence this system was indeed "Haskell done right", which is why I'm asking).

View on HN

Well, its hard to tell not being a haskell advocate, but the people building the systems were haskell experts with years and years of that being their only language and were extremely particular about the implementation, which is part of the reason why they justified the 10 requests per second part, is because it was "done right". My understanding is that haskell is designed is such a way that certain things are impossible to do any way but the "right way", so its also just fundamental by merit of the fact that they were using haskell to solve those particular problems. But it was mostly clout and the fact that the implementation was so thorough and the people building it were like phd level experts in haskell/category theory.

I think what you witnessed is the fact that being an expert in programming language theory or category theory, does not make you a good software engineer.

Haskell is surprisingly well suited for back-end services (e.g REST). Warp (an HTTP server), Servant (a way to define your backend API), and Mio [1] (the Haskell network IO implementation) are amazingly performant and scalable.

Of course, that does not prevent you from messing up on the business logic level. I suspect that they lacked awareness of performance implications of their choices, this is not something Haskell will save you from. On the contrary, parts of the Haskell community do tend to go to over-abstraction, and I believe this does have a negative effect on people writing production software.

[1] https://dl.acm.org/doi/abs/10.1145/2503778.2503790

Reply on news.ycombinator.com