3 ms·

Wow this is great! Fixing Haskell's arcane record system would be a huge step towards more mainstream adoption. It was certainly my largest pain point with the

• eru 6y ago
  That's interesting! I would have expected space-buildups from accidental laziness to be a bigger problem in production?
  • whateveracct 6y ago
    That is not an especially big production problem. Of course you don't want it to happen. But it rarely happens. And it happens even less if you use -XStrictData or manually make your record fields strict since that's by far the most common cause: lazy records used as accumulators. I would say in my 5 years of production Haskell, I've seen that sort of thing deployed in production _maybe_ once, and I've run into it during development once or twice. One time it was in integration testing, and a simple heap profile made it clear it was in a library dependency. And a quick look at the library source was enough to diagnose it. It was like an hour or two tops from "we have a space leak somewhere" to "here's a PR to a third-party library fixing the leak."
    • eru 6y ago
      Thanks! Most of my production experience with 'Haskell' was with Standard Chartered's Mu dialect, which is strict anyway. A bit of a problem when you first start using Haskell seriously is that the IO mechanisms built into the prelude are very slow once you get to even only a few MiB. That's easily remedied by switching to eg ByteStrings, but it's still a bit annoying that what the language presents as the 'default' is such a toy implementation.