Developer tools (build system etc)

NOTE: this page is deprecated. I am not updating it anymore.


By Artyom Kazak aka @availablegreen
Last update: January 4, 2021

Build tools

Nix + Cabal + hpack.

The reason I use Nix is that it gives me deterministic-ish builds + great caching with Cachix + it installs GHC for me automatically. I don't want to use ghcup. If something takes more than one command to set up a dev environment, it's out.

I used to really like Stack, but after seeing that people regularly face problems (linking, etc) that can't be solved by any way other than rm -rf .stack-work and sometimes even rm -rf ~/.stack, I changed my mind.

Plus, with Nix I don't have to pollute my laptop with "install this specific version of OpenSSL globally" and so on.

Not having module autodiscovery is often a dealbreaker, so I also use hpack and just call it manually when I need to.

Code editor

Emacs + good old haskell-mode.

I think VSCode is probably the best Haskell IDE at the moment, but I've been using Emacs for eight years and I don't mind. Plus Magit is still the best Git GUI in existence.

For jump-to-definition, I have hasktags + a browser search shortcut that expands hg foo into a Hoogle search for function foo.

For autocomplete, I use Tabnine, which isn't great, but never breaks and doesn't care what GHC version I have.

I don't use haskell-language-server, for no good reason other than "I don't see a particular need". However, if you want IDE-like experience, you should use haskell-language-server.

Code formatter

Ormolu or Fourmolu.

I like the idea of one true formatter. Ormolu is also the only formatter that does not have severe bugs.

I do use Fourmolu for some projects that really need leading commas, though, and I think Ormolu has misspent its weirdness budget. If you don't like Ormolu's style, give Fourmolu a go.

Code linter

Either none at all, or HLint with most hints disabled.

I find HLint sometimes useful, mostly neutral, and occasionally harmful.

I will grant that HLint reduces the number of pull request review squabbles. That's true. But otherwise — let's say, the advice to remove names from your code isn't great. The advice to remove do when you only have one thing in the do block is also not great, because sometimes it means you end up adding and removing do neurotically. The advice to remove extra parentheses from your code is useless. Etc.

An up-and-coming contender is Stan, which I look forward to revisiting in a year or so.

Update 04-01-20: Neil says that the do hint is no longer enabled by default. Yay!