5 ms·

Anyone using Haskell to drive their business is making a huge mistake in my experience. Haskell2010 is a fine language. Unfortunately, the ecosystem has centere

Anyone using Haskell to drive their business is making a huge mistake in my experience. Haskell2010 is a fine language. Unfortunately, the ecosystem has centered around whatever the latest version of GHC is, with its millions of language extensions and breaking the world with changes like https://gitlab.haskell.org/ghc/ghc/issues/10365 https://gitlab.haskell.org/ghc/ghc/issues/10365 and https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of.... Which is fine if you're doing research or building tools for fun! But it makes an absolutely awful industrial experience when you want to ship features and not get stuck on a bit rotted version of GHC. edit: It's unfortunate that people are downvoting me for offering my experience, especially on a post that wants to make Haskell more attractive to being used in the industry.

willtim 6y ago
You have a very valid point. As someone who uses Haskell professionally in a large organisation, I can honestly say that past changes such as FTP and AMP have added very little but caused significant issues for both academic and industrial users. GHC is no longer a Haskell 2010 compiler and unfortunately there seems little interest in the community for creating a new Haskell standard.
platz 6y ago
these issues probably did not cause a lot of problems for production software
- moreaccountspls 6y ago
  Huh? My whole comment is about the fact that they DID cause a lot of problems for production software. The company wrote their flagship product in Haskell, and there is a pretty large chance that that decision will doom them because of the choice to use Haskell. It's unfortunate because the product has a great market fit. If they had choose pretty much any other tech stack, they would be killing it.
  - deleted 6y ago
    [deleted]
  - codygman 6y ago
    I recall refractors from those proposal being very mechanical and easy to automate. Maybe my memory is fuzzy... But if not can you give an example where that wasn't the case?
    - moreaccountspls 6y ago
      Yes. An example was moving to the version of GHC where the semigroup change happened. The codebase was using this library: https://github.com/brendanhay/gogol https://github.com/brendanhay/gogol. The library dropped support for one version of Google's API for another version. Fair enough, except the old version would no longer work because of the semigroup change. So I ended up having to waste a ton of time completely changing on how we were using a library to satisfy the semigroup change. Again, this is the problem. The ecosystem tends to only aim at GHC latest because of the attitude that "its mechanical to change!". Yeah, for the code you write maybe, but if the dependencies have that attitude, all of sudden upgrades can be a huge effort.
      - tome 6y ago
        Would fixing it require more than adding instance Semigroup t where (<>) = mappend for every type t that has a Monoid instance? That would be tedious for sure, and very frustrating that a maintainer wouldn't support their package sufficiently well to do that for you, but still seems to fall under the description of "mechanical".
      - dllthomas 6y ago
        That seems like a problem with gogol dropping support for relevant features, rather than with the semigroup change in particular. If you didn't want to keep up to date with the library more generally, the semigroup change in isolation could have been dealt with by forking the library in question. Which isn't to say this isn't still indicative of friction in the Haskell ecosystem when it comes to building a large system for production.
sjakobi 6y ago
There a several companies who benefit massively from using Haskell, not least by attracting talent! The most recent instance is probably Juspay: https://github.com/juspay https://github.com/juspay

willtim 6y ago

You have a very valid point. As someone who uses Haskell professionally in a large organisation, I can honestly say that past changes such as FTP and AMP have added very little but caused significant issues for both academic and industrial users. GHC is no longer a Haskell 2010 compiler and unfortunately there seems little interest in the community for creating a new Haskell standard.

platz 6y ago

these issues probably did not cause a lot of problems for production software

moreaccountspls 6y ago
Huh? My whole comment is about the fact that they DID cause a lot of problems for production software. The company wrote their flagship product in Haskell, and there is a pretty large chance that that decision will doom them because of the choice to use Haskell. It's unfortunate because the product has a great market fit. If they had choose pretty much any other tech stack, they would be killing it.
- deleted 6y ago
  [deleted]
- codygman 6y ago
  I recall refractors from those proposal being very mechanical and easy to automate. Maybe my memory is fuzzy... But if not can you give an example where that wasn't the case?
  - moreaccountspls 6y ago
    Yes. An example was moving to the version of GHC where the semigroup change happened. The codebase was using this library: https://github.com/brendanhay/gogol https://github.com/brendanhay/gogol. The library dropped support for one version of Google's API for another version. Fair enough, except the old version would no longer work because of the semigroup change. So I ended up having to waste a ton of time completely changing on how we were using a library to satisfy the semigroup change. Again, this is the problem. The ecosystem tends to only aim at GHC latest because of the attitude that "its mechanical to change!". Yeah, for the code you write maybe, but if the dependencies have that attitude, all of sudden upgrades can be a huge effort.
    - tome 6y ago
      Would fixing it require more than adding instance Semigroup t where (<>) = mappend for every type t that has a Monoid instance? That would be tedious for sure, and very frustrating that a maintainer wouldn't support their package sufficiently well to do that for you, but still seems to fall under the description of "mechanical".
    - dllthomas 6y ago
      That seems like a problem with gogol dropping support for relevant features, rather than with the semigroup change in particular. If you didn't want to keep up to date with the library more generally, the semigroup change in isolation could have been dealt with by forking the library in question. Which isn't to say this isn't still indicative of friction in the Haskell ecosystem when it comes to building a large system for production.

sjakobi 6y ago

There a several companies who benefit massively from using Haskell, not least by attracting talent! The most recent instance is probably Juspay: https://github.com/juspay https://github.com/juspay