3 ms·

> 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, user

by pyrale 4y ago

> 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?

picozeta 4y ago
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.
- pyrale 4y ago
  > And I spent way less time learning Go than learning Haskell. ...And you've got what you paid for.
  - astrange 4y ago
    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.
  - andi999 4y ago
    Maybe Haskell is overpriced?
    - pyrale 4y ago
      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 ;)
Karrot_Kream 4y ago
> 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.
- pyrale 4y ago
  > 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.

by pyrale 4y ago

picozeta 4y ago

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.

pyrale 4y ago
> And I spent way less time learning Go than learning Haskell. ...And you've got what you paid for.
- astrange 4y ago
  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.
- andi999 4y ago
  Maybe Haskell is overpriced?
  - pyrale 4y ago
    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 ;)

Karrot_Kream 4y ago

> 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.

pyrale 4y ago
> 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.