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.
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, 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?
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.
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.
And I spent way less time learning Go than learning Haskell.
...And you've got what you paid for.
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.
Haskell usage in companies is currently niche at best. It's hard to know what you would consider reasonable use of the language if you believe it's currently overhyped. Maybe your idea of hype relies on conference talks or some other metric I don't get?
> in my personal opinion, you don't gain that much if you compare it to something like Rust, Java or even Go.
Rust is pretty similar to Haskell in terms of type system experience, the main difference being that, when you don't really care about how memory is used, Rust forces you to handle it. Any GC'd language will feel refreshing if you're annoyed by that. Aside from that, I don't challenge that Rust is a great language to program in.
Java's usability is built on a fundamentally different model: it benefits from decades of investment in IDEs, and all professional java users I know use it extensively. While a haskeller will rely on types to perform refactoring, a java dev will refactor using the IDE, with an equivalent peace of mind. Java's typesystem is poor, but it doesn't really matter in users' development experience.
I don't have much positive stuff to say about Go, and even less about its typesystem. You may find better advocates for this one.
> Lastly it's just incredible hard to estimate runtime characteristics
Most use cases don't care about that. You quoted Java earlier, a language in which most devs never ever really delve into runtime performance and simply let the runtime do its stuff. As it turns out, it's usually good enough.
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.
> If Haskell is such an advanced language to make implementing reliable SW such a breeze
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?