> do you really have to understand language extensions?
You do when your code doesn't compile and you're trying to figure out what the error message means, or when the library you want to use makes heavy use of it for even basic functionality.
> These days one just enables GHC2021
My experience was pre-GHC2021. I basically had to enable at a minimum 5-6 language extensions in every single file.
> Mostly they're just about removing unnecessary restrictions from the older standard.
Yeah, those ones are usually fine. I have zero objection to things like FlexibleInstances or DeriveFoldable.
> Could you give an example?
I believe I was trying to implement Central Authentication Service using Servant. However, that required returning a custom HTTP status code. There has been an open Github issue for this since 2017, but it seems to require basically rewriting the entire framework: https://github.com/haskell-servant/servant/issues/732
Looking back at it now Servant does have "ServerError", but that basically requires giving up all the advantages Servant claims to have and I believe it was not a viable option at the time. Looking at the timeline I was probably also on Servant 0.15, and there seems to have been a rewrite since then.
I vaguely recall running into a similar issue trying to interact with a database, but I can't remember the details of that.
I'm in a tricky position because I'm spending quite a lot of effort trying to improve the Haskell ecosystem, and although people report a lot of difficulty with language extensions I don't actually understand why. I suspect the problem is with something else, but it gets attributed to "language extensions" because that's the element that was most visible when the problem occurred.
Anyway, I don't mean to badger you, so feel free to ignore me if it's not a good use of your time, but I do have more thoughts and questions.
> I basically had to enable at a minimum 5-6 language extensions in every single file.
Sure, but I don't see a problem with that, per se. I routinely enable 20 language extensions in a single file! They're mostly just removing restrictions, as I said. It gets a bit tedious but nothing more than that.
> I believe I was trying to implement Central Authentication Service using Servant
Aha! Servant uses a style of programming (often called "type level" but I'm not really completely sure that's accurate) that I find rather inflexible. I would be very hesitant to use Servant myself, personally.
Is it possible that the problems you experienced were actually to do with the inflexibility with Servant itself, but the problems have been attributed to language extensions, since you were required to add them to make Servant work?
You do when your code doesn't compile and you're trying to figure out what the error message means, or when the library you want to use makes heavy use of it for even basic functionality.
> These days one just enables GHC2021
My experience was pre-GHC2021. I basically had to enable at a minimum 5-6 language extensions in every single file.
> Mostly they're just about removing unnecessary restrictions from the older standard.
Yeah, those ones are usually fine. I have zero objection to things like FlexibleInstances or DeriveFoldable.
> Could you give an example?
I believe I was trying to implement Central Authentication Service using Servant. However, that required returning a custom HTTP status code. There has been an open Github issue for this since 2017, but it seems to require basically rewriting the entire framework: https://github.com/haskell-servant/servant/issues/732
Looking back at it now Servant does have "ServerError", but that basically requires giving up all the advantages Servant claims to have and I believe it was not a viable option at the time. Looking at the timeline I was probably also on Servant 0.15, and there seems to have been a rewrite since then.
I vaguely recall running into a similar issue trying to interact with a database, but I can't remember the details of that.