Hacker News Reader

Comment by picozeta | Hacker News Reader

> [...] Maybe your idea of hype relies on conference talks or some other metric I don't get?

Yes, I'm referring to programmer circle related social networks (HN, r/programming, ...).

> It's quite surprising that aside from Fortran, C derivatives and Rust, no one gives a damn about performance, but when it's haskell, it suddenly becomes a problem.

Because performance problems are particularly hard to solve in Haskell due to its high level of abstraction.

> Is that some kind of strawman where if haskell doesn't deliver on being touted as the gift of God to programmers, then it's bad?

Yes, given the fact that it's praised to such a high degree, users might have extremely high expectations, but are likely to be underwhelmed if it does not solve their problems in a vastly superior way.

View on HN

> Because performance problems are particularly hard to solve in Haskell due to its high level of abstraction.

Does not match my experience. Haskell typically compiles to quite performant code, at least for all the cases that I’ve used it for.

Then few times I had to optimize anything for performance, it did not feel different than other languages. It was in almost every case about the architecture of the code and not something to do with the language itself.

> Yes, I'm referring to programmer circle related social networks (HN, r/programming, ...).

> Yes, given the fact that it's praised to such a high degree, users might have extremely high expectations

May I suggest the problem is not with the language, then? As a fellow HNer that you can trust, I also have an extremely well-made bridge to sell you if you're interested.

> Because performance problems are particularly hard to solve in Haskell due to its high level of abstraction.

That doesn't match with my experience using the language. But again, how often do you have to solve performance issues that are more complex than a misplaced quadratic function in other languages? If it's frequent enough, wouldn't you consider using a language like rust or CPP rather than something like Java, Go or Python?

Yes, if performance is the main concern, Rust looks good. However if I can get by with GC I still would choose something like Go, as I am just getting to a working solution faster.

And I spent way less time learning Go than learning Haskell.

> And I spent way less time learning Go than learning Haskell.

...And you've got what you paid for.

Google paid quite a lot internally to develop Go, and despite its many flaws it at least has mechanical sympathy for the computers it runs on.

I've read GHC assembly and it seems to be intentionally trying to run poorly - eg it calls everything through unpredictable function pointers. No, this isn't CPUs' fault, as GHC people do try to be optimal, they are just failing. jhc produced good code but isn't maintained afaik.

Maybe Haskell is overpriced?

In terms of learning, Haskell is like a lootbox game. You can definitely do great things with a minimal budget, but people get addicted and end up spending fortunes on additional content ;)

> But again, how often do you have to solve performance issues that are more complex than a misplaced quadratic function in other languages? If it's frequent enough, wouldn't you consider using a language like rust or CPP rather than something like Java, Go or Python?

Why? This doesn't agree with my experience using Java or Go at all. Both languages have ways to reuse objects that significantly decrease GC pressure for bottlenecks to achieve competitive performance. Also anyone running net services at scale frequently runs into performance issues that are much more thorny than misplaced quadratic functions (are you deserializing JSON in a hot loop? is your HTTP connection pool too large? is your hash table too large, leading to significant collisions?)

Rust or C++ is overkill when reusing some objects, moving data structures, or memoizing some serde is all you need. Reasoning about them in Haskell can also be quite difficult, especially if you build a lazy chain of operations that leads to executing an expensive operation frequently in a hot loop, or forget to preallocate HTTP connections in a pool, or something like that. It's a high cost to pay for a better type system and awkwardly unifying abstractions.

> Both languages have ways to reuse objects that significantly decrease GC pressure for bottlenecks to achieve competitive performance.

I agree with that, but the consequence of these things is that developers don't have to care about it themselves. Thus these languages are usually good enough that optimization is not a concern for most devs in these ecosystems.

> (are you deserializing JSON in a hot loop? is your HTTP connection pool too large? is your hash table too large, leading to significant collisions?)

None of these things are language-related, though.

> Reasoning about them in Haskell can also be quite difficult

We didn't have specific trouble when this kind of problem came up, maybe your mileage is different ? Being used to it, it's kind of hard to understand what specifically you find hard in this.

Reply on news.ycombinator.com