My snarky comment here is that if the type system isn’t all about guarantees, that significantly diminishes its usefulness. (ghc has also gotten much better in this respect.)
Conversation
And if I were to be equally snarky in turn, then I’d say that I think people who attempt to get too fancy with “DSL” design in Haskell deserve to have their programs broken with every GHC release to teach them to knock it off. ;)
2
1
Alexis, I’ve looked up to you since forever, and you’re the last person from which I expect “you’re holding it wrong” defenses :-).
It’s great you have a great workflow, but it doesn’t really help others.
1
Hey, I prefaced it with a disclaimer that I was being snarky! :) Of course I would never actually advocate for such a thing…
…even if maybe sometimes I wish I could…
1
1
I got those vibes from the whole thread (see below), since I’ve seen many complaints these days suggesting otherwise…
Quote Tweet
Replying to @lexi_lambda @samth and @RaeHaskell
Perhaps you don’t fully realize how irrelevant these issues are in Haskell because the tooling makes them trivial to work around. If one of your deps is broken by this, you fork it, delete the /= definition, submit a PR, and add your fork to your build. This takes minutes.
1
I admit that something I have historically been a lot more aggressive about than virtually anything else is the Haskell packaging story, because I legitimately do not understand why people bag on it as much as they do and would frankly love for someone to argue with me about it!
2
2
The new cabal stuff seems to have made it much nicer to work with! There are still packaging related things that make me wary about using Haskell more heavily. I could explain further if you're interested, but I'm more of an outsider and I might be mistaken about some things.
1
1
What do you have in mind?
1
Thinking for example about how (AFAIK) cabal requires single version of a package in a compilation unit. There's tradeoffs around this, but imo it's nicer for gradual upgrades, and leads to less annoyance when you can't install packages due to an incompatible ancestor dependency.
1
I’m not sure I know what that means, what is the alternative?
2
Allow multiple versions of the same package if there is a version range conflict between dependencies. The way Rust handles linking is to use a hash to distinguish the crate versions.
Downside is you need to keep on top of duplicates, and you run into errors if you want to use types of one version with a crate that expects another version (without manually converting). Still, I think it's a better failure mode than not allowing you to compile.
1