Welcome! These are great getting-started-experience notes, so thanks! You are a contributor already. I’ll share my 2c:
The interaction of ghcup, stack, cabal and the language server have been my biggest time sink when moving between projects, cloning others repos. I found initial set up was quite straight forward following ghcup guides and helix is my preferred editor and the language server just worked initially. As soon as I started cloning other repos or trying out different projects with cabal and stack the pain commenced. Guilty confession, I’ve done multiple nukes.
I can certainly believe this.
The full details are probably lost in time and/or far too much work to recount, but I’m sure any more you remember would be interesting.
The import conventions, pragma, preludes, modules, etc. is something I’m a little nervous about having to deal with as it doesn’t seem intuitive at this stage.
-
pragmas: I assume this mainly means GHC language extensions. I have never paid much attention to them; I just learned the most useful ones lazily when GHC told me which one to add, to permit some code I had written. I’d do a little research at that time to check that extension’s reputation, since I know not all of them are wise to use, eg because they have been superseded or because they make error messages more obscure. If writing new code, I’d probably stick GHC2024
in my cabal file or wherever to be sure I’m using modern defaults.
-
preludes: As a learner, just stick with the standard prelude. None of the others have achieved widespread use.
-
modules: The way GHCI in particular handles packages, files, modules, and namespaces is pretty confusing. If that’s causing problems, I would study the GHC(I) user guide once for background knowledge. (I strongly recommend this for GHC, cabal and stack generally, also.)
-
imports: The variations of import
syntax, can be a bit confusing in the beginning. I’d keep import
’s doc, and/or a bunch of existing Haskell code examples handy. The location (package and hierarchical module name) of things you may want to import, can also be confusing; keep hoogle handy, plus skim some of the module outlines and haddocks of core packages like base, containers, time, etc. Be aware that you can occasionally find the same module name provided by multiple packages - it’s rare, but confusing when it happens; that’s when the PackageImports
extension is useful.
Hoogle is great but as a newcomer it is information overload at times. Often I wish I could just find an example code snippet but am lost somewhere deep in a series of → -> → entries. I am assuming this will get better with familiarity.
Perhaps collecting a few code bases with similar level / topic to what you’re doing can be a good source of examples. Github code search might also be worthwhile.
I don’t know whether I have to opt in to some of the ghc compiler flags that would appear to have no downside (-Wincomplete-uni-patterns for example) when switching between ghc versions.
As a learner, I wouldn’t bother with anything non-default unless you hit some real need. When you are shipping complex packages and needing to prevent bugs and build failures, that’s a good time to crank up the warnings and add -Werror.
Analysis paralysis about packages has been quite real for me. For example, I have used the fpcomplete haskell articles and they espouse the benefits of rio but it’s failing tests and the most recent issue is from 2023 so did the community move away from that or did the base library adopt/change things? I hope I feel more comfortable with these decisions in time.
Yes, rio hasn’t achieved much traction in the wider haskell sphere. I’d guess you’d see it used quietly in industrial codebases. Like custom preludes feel free to use it for learning or building but you’ll be a bit apart from the mainstream learning resources.
Generally to get a sense of what’s being actively used, check the hackage page for recent upload dates and reverse dependencies. You can also ask in chat, or you can check what’s packaged in stackage LTS.
Indentation has been a frequent source of errors; I am indebted to ormolu.
You do get used to this. I use simple two-space indents in VS Code, and simply add more or less when it shows me red squiggles.
:t in ghci is the best thing since sliced bread
So is ghcid
for rapid compiler feedback, and so is mouse-over in VS Code + HLS if you get those set up.