Type systems are leaky abstractions. [...] I think it is a good idea design wise to account for that possibility, and give people the ability to completely bin

Type systems are leaky abstractions. [...] I think it is a good idea design wise to account for that possibility, and give people the ability to completely bin the type system when they need to. Agreed on both counts, if we're talking about having escape hatches like `unsafePerformIO`. Maybe even `undefined`. But I grimace a little whenever I see someone criticising the prevalence of runtime problems like, say, null pointer exceptions in Java, and then in practically their next breath advocating a functional programming language with a better type system like Haskell... and giving a neat example that will quite happily compile and then crash at runtime when given an empty list as input because it used a partial function like `head` without checking. This sort of gaping hole in the protection of the type system is less welcome. Could you elaborate [on 27 different ways to handle errors]? I think gizmo686 did a nice job of covering this in another reply to your comment, and I added some further thoughts of my own in a reply there. In our current context, I note in passing that the issue of throwing from pure code when catching needs IO is another somewhat counter-intuitive result that we might instinctively expect the type system to protect against. Compared to which language [can Haskell not handle basic record types very elegantly]? Perhaps C, C++, C#, Java, and friends as a starting point? At least the names of members of structs/classes there are used in context and don't clash with the same name used in a different context. Haskell also has the same challenge as any functional language when it comes to constructing new values from existing ones where there is deep nesting. As you say, lenses can help there, but bring some additional complexity of their own. Compared to what? Would you consider Haskell better for type safety than say Java/C#? Yes, certainly. I'd much rather write software that involves complicated logic and needs high reliability or longevity in a language like Haskell than a language like Java, other things being equal. I'm just wary of putting Haskell up on too high a pedestal, partly to avoid setting expectations too high for those not familiar with it yet, and partly because I think a lot of mainstream languages could benefit from relatively simple improvements in their type systems without necessarily encouraging the "using types for non-trivial things requires five PhDs" stereotype. I assume you meant the features you noted above as missing (easy record types, coherent error handling, lack of partial functions) in Haskell but widely available in other languages -- could you note which ones you had in mind? Yes, for example the struct/class member naming mentioned above. Almost every statically typed language I have ever used does records better than Haskell, because Haskell doesn't really support record types at all, it just has a bit of syntactic sugar that creates the illusion of that support if you don't look too closely. (This assumes the basic language without the various relatively recent GHC extensions/proposals, of course.)