4 ms·

I don't think this is even a Haskell criticism as much as it is a software engineer criticism. You can be ignorant about hardware in most languages, especially

I don't think this is even a Haskell criticism as much as it is a software engineer criticism. You can be ignorant about hardware in most languages, especially Python. Going by what you've said, it sounds like you want the industry to return to C/C++ for everything. As for Haskell, I'm not experienced enough to make a real defense of it, but I've been told the compiler is pretty damn good. It's a decently fast language. I don't know how it compares to something like Go, and of course for very high-performance needs you probably shouldn't use it, but letting it take over isn't the worst thing in the world, and you can still use knowledge of hardware to make it faster. But if that's not enough, just use Rust or something. It's basically Haskell-lite anyway.

azurelake 5y ago
Laziness by default makes it extremely hard to reason about performance, at least for me. So Rust is actually far closer to C/C++ than Haskell lite in terms of being able to think about how the code you write maps to the physical machine.
Karrot_Kream 5y ago
> You can be ignorant about hardware in most languages, especially Python You're thinking in terms of languages and not systems. If you've ever built systems at scale, you'll know that abstractions break down. The best of us write leaky abstractions. When the time comes to debug a leaky abstraction, you need to open up the hood. This means checking how many connections are open, checking whether you're flushing too often to disk, checking if your DB queries are locking up tables, checking when you're thrashing CPU, checking if you're not pooling a connection properly, etc. That's when you need to break down the abstraction layers and break out tools like iperf or Wireshark. Languages like Haskell create such a different execution model (with monads and lazy execution) that it makes it really hard to break through its abstractions and understand what's going on. I've had similar experiences to the author. I've written Haskell for fun and worked in Scala. Most of the folks who have your viewpoint have (in my experience) not worked in a situation where these issues come up. Either the scale of the problem is low so powerful abstractions are more powerful than deconstructing them or they work in problem domains where standards around correctness are a lot lower and programmer happiness is paramount. But if you've ever been in a position where you need to write a high-scale or high-reliability application, languages with highly abstract execution models prove more a liability than an asset. In that regard both Erlang and Rust offer a much more concrete execution model that's a lot easier to reason about than Haskell or monadic Scala offers, at least in my experience.
- tome 5y ago
  > This means checking how many connections are open, checking whether you're flushing too often to disk, checking if your DB queries are locking up tables, checking when you're thrashing CPU, checking if you're not pooling a connection properly, etc. I’m not sure what you mean. Industrial Haskell users can and do check all of these things like their Python and C++ counterparts.
  - Karrot_Kream 5y ago
    It's not that they don't check those things, it's that Haskell's tower of abstractions makes it much harder to figure out where issues are coming up. In most apps at most you're dealing with GC time other than your actual operations. In Haskell you're dealing with laziness and monad composition atop just GC time.

azurelake 5y ago

Laziness by default makes it extremely hard to reason about performance, at least for me. So Rust is actually far closer to C/C++ than Haskell lite in terms of being able to think about how the code you write maps to the physical machine.

Karrot_Kream 5y ago

> You can be ignorant about hardware in most languages, especially Python You're thinking in terms of languages and not systems. If you've ever built systems at scale, you'll know that abstractions break down. The best of us write leaky abstractions. When the time comes to debug a leaky abstraction, you need to open up the hood. This means checking how many connections are open, checking whether you're flushing too often to disk, checking if your DB queries are locking up tables, checking when you're thrashing CPU, checking if you're not pooling a connection properly, etc. That's when you need to break down the abstraction layers and break out tools like iperf or Wireshark. Languages like Haskell create such a different execution model (with monads and lazy execution) that it makes it really hard to break through its abstractions and understand what's going on. I've had similar experiences to the author. I've written Haskell for fun and worked in Scala. Most of the folks who have your viewpoint have (in my experience) not worked in a situation where these issues come up. Either the scale of the problem is low so powerful abstractions are more powerful than deconstructing them or they work in problem domains where standards around correctness are a lot lower and programmer happiness is paramount. But if you've ever been in a position where you need to write a high-scale or high-reliability application, languages with highly abstract execution models prove more a liability than an asset. In that regard both Erlang and Rust offer a much more concrete execution model that's a lot easier to reason about than Haskell or monadic Scala offers, at least in my experience.

tome 5y ago
> This means checking how many connections are open, checking whether you're flushing too often to disk, checking if your DB queries are locking up tables, checking when you're thrashing CPU, checking if you're not pooling a connection properly, etc. I’m not sure what you mean. Industrial Haskell users can and do check all of these things like their Python and C++ counterparts.
- Karrot_Kream 5y ago
  It's not that they don't check those things, it's that Haskell's tower of abstractions makes it much harder to figure out where issues are coming up. In most apps at most you're dealing with GC time other than your actual operations. In Haskell you're dealing with laziness and monad composition atop just GC time.