I was deep into Haskell and used it as my primary language from 2012-2015, but switched over to Rust around that point. I've been thinking about trying a mid-size hobby project in Haskell to get updated on the new state of the art.
Some things I have heard tangentially (and may be misremembering):
- Field accessors (i.e. `myObject.field` instead of `field myObject`)
- Monad hierarchy refactoring (monad of no return)
- LiquidHaskell making some inroads
How is package management these days? Is cabal hell still a thing? How's the IDE situation?
Tooling has improved massively in general. ghcup can install and manage versions of Cabal/Stack/GHC/etc automatically. The Haskell language server provides reasonable editor-agnostic IDE functionality; I've been using it for a while now and have found it to be useful and solid.
The language itself has had a bunch of small quality-of-life improvements. The foundation still feels the same—not a major change like jumping to dependent types or something—but lots of rough edges have been sanded off.
I've been using Haskell for over a decade now and I'm very happy with the progress of the language and the ecosystem over the last several years.
We use Stack together with Nix to pin all dependencies. That works very well.
> Is cabal hell still a thing?
No.
> How's the IDE situation?
Much better than it was. Haskell Language Server (HLS) has been a game changer. It works very well and can be used with different editors (easy to install for VS Code for example).
Could you elaborate on the path you took here? Sounds interesting
I've figured out stack and it's pretty great.
My editing cycle is pretty terrible. usually vim in one terminal and another terminal to run ghci or stack build. That's ok, it lets me work through my toy problems.
But compared to IntelliJ or even coq and proof-general, it's a lot rougher to loop through type in new code, run it, fix or next batch of new code.
obviously developers are going to use whatever they want, but it would be really nice to see a setup with _anything_ emacs, visual studio, atom whatever. and show how to get to that setup, and how to quickly test, analyze performance, refactor.
Refactoring is Haskell's super-power. I change things and chase compiler errors, and it works well enough. Compared to even java/eclipse 15 years ago it feels primitive. it works, I can get by. I'd like to see how "grown ups" do it.
I'm using a mac m1 I cannot get stack and the Haskell language server to play nice for VSCode.
I'm also not a huge fan of YAML in general for configuration. Rust uses Toml, Elixir literally just uses elixir itself for configuration.
What's the worst part of Haskell tooling in your opinion?
I'd say 25% of my Haskelling happens at a computer though.
Where do you do the rest of your Haskelling?
Are there other popular Haskell tools? Or is it more of an academic language? I was surprised to see it on the GitHub repo.
GitHub uses Haskell for all its code analyzation, so you're interacting with it all the time! => https://github.com/github/semantic
I'll do what I can to improve the situation, but I need to know which packages precisely you are talking about.
At the end of the day we did not go forward with that. The reasons mostly were:
1. Even though I used a lot of my "social credit" on this everybody was scared of it. Mostly because of the vibe that comes with Haskell.
2. Purely functional languages come with lots of concepts that are unfamiliar to most programmers (everybody in my team was well equipped with CS degree and theoretical knowledge but still those concepts were new-ish).
3. The higher in company hierarchy the more people were scared (this was a critical project for the whole company of ~22k people).
4. We couldn't figure out debugging. Our codebase was ~40k generated lines of code (type definitions, basic accessor functions and so on) plus ~10k LoC we would write on top of that. The only VSCode-based debugging I was able to figure out was basically loading it in GHCi and then doing the debugging which was fine. The problem was the load itself. It took ages because it recompiled majority of the codebase on load. No precompiled parts were used. Result was that every debugging session took minutes to start up.
On the other hand Liquid Haskell has a great potential and I hope that there is a future in which we have similar tools in more common languages. As the complexity of the codebase grows it become more important to have a tool to provide additional guarantees. We did not have much of the code on its own but it was packed with complexity and dependencies. Liquid Haskell seemed to provide a tool that does not get into your way when you don't need it but it available when you want it.
¹ https://survey.stackoverflow.co/2022/#most-loved-dreaded-and...
