I tend to believe in the value of those magic moments and think we should raise expectations in terms of training and practice to appreciate and understand them (I've never used Finagle so I don't know the specifics of it, maybe it is beyond any reasonable standard of comprehensibility).

The problem is when the magic isn't happening. How do you convince yourself or someone you work with to take off the wizard hat, come down out of the clouds and implement the naive/verbose/ugly solution because the elegant stroke of genius hasn't come and the feature is taking forever?

This is where Go and PHP shine, less temptation to guild the lily.

> I would argue that Go has been successful largely because everything that’s happening is “out in the open”, where the average developer can see it. It’s a very different philosophy, one that I think the quote-creator aligns with better than your typical Haskell devotee.

This is why I like Go. It makes it difficult to write code that doesn't take basically the same approach any other, similar code would. When you start trying to get abstract or do anything cute, it hurts just enough that you won't do it unless there's an actual need, not just some aesthetic preference.

Consequently, I can hop in to just about any of my dependencies and read them immediately. No, "huh, I haven't seen that language feature before" or "WTF is that symbol even?" or "... but where does it actually do anything?" or "oh great they've imported a library that basically turns it into an entirely different language".

The community's also been really good at avoiding adding abstractions through libraries, so you don't end up with the mess that Javascript had for years with multiple competing Promise libraries in wide use or a dozen competing module systems or any of that crap. There's some experimentation but it rarely gets out of hand.

> The problem really nice abstractions have is that they encode too much into too little code.

Sorry, I don't think I made myself very clear. I wasn't talking about concise code. I was talking about designing your system right, and deciding where you want to set boundaries and what you want to keep flexible. And sometimes: what do you want to encode in types, and what do you want to check at runtime?

Also what properties and invariants do you want your system to have? (See also property based testing.)

Calling all of this a design of abstractions was not the most clear word choice on my part. Sorry for that.

However, to defend a point I didn't make:

Sometimes it does make sense to shorten your code a lot. If you can express your solution in 10% of the lines, it might be worthwhile, even if each line is twice as hard to understand now.

That code might benefit from some explanation, and generous annotations, though. And plenty of properties tested.

Scala is not necessarily a detour in this discussion. It's arguably the most functional language among mainstream ones. And for better or worse its ecosystem seems to be influenced by old Haskell hands much more than one would expect. So what we have seen in the last ten years is probably a good proxy for using a real functional language in the industry.

Akka comes to mind as another example of what you said about Finagle. It works great and even has voluminous documentation. But every time I try to click through it in Idea to see how it works I kind of don't see it. This contrast with most other libraries is very real. From speaking to other people I know that I'm not the only one who feels this way. Broadening horizons aside, I'd rather not have production issues with such a codebase.

Personally I don't doubt that Haskell developers are smarter than me. Though I strongly suspect that they come from a hard to reproduce background (PL theory majors? CS postgrads? theoretical physicists?). And not that many companies require this level of sophistication.

There's a huge disconnect I see in the real world. Intellectual bottom scrapers such as JS/golang are increasingly popular. Yes, we see golang catching up with Java ten years later than was necessary but it only confirms the observation. Scala and even Kotlin (F# too?) are not that widely used for how practical they are. In this world I see no place to be found without a looking glass for something as esoteric as Haskell, lazy evaluation and all. And we've had this exact conversation for a decade already.