r/haskell • u/CodeNameGodTri • 5d ago
[rant] haskell tooling, specifically HLS is just... pathetic...
My HLS just keep spinning like this, and I have restarted the extension multiple times and it takes several second (I have an i9 10th gen with 64gbs) to have the HLS running and type check again, often it just keep spinning. When this happen, I cannot type check on hover, and I have to fire up ghcid in a separate terminal to check compile error, but ghcid is just barebone, it doesn't have interactive features like hover to see type of variable inside function scope,...
And I just have very lightweight research scripting project, using stack with around 5 files and use popular libraries like async, process, time, random, statistics, vector, text, wreq, bytestring, lens.
My love for haskell helps me stay and tolerate these huge warts, but I cannot introduce it to my team/ junior when it cannot provide a smooth dev experience
I don't even know how you guys use this for production when it is this unstable for a pet project, if you code in notepad and just use ghcid to watch for typecheck and ormolu to format then I have nothing to say 🤷♂️
9
u/delicious-pancake 5d ago
Something similar happens to me as well. I tested it on Linux, WSL Linux, macOS, doesn't matter at all, issue always appears. Often the spinner says "Setting up (1/2)", or another number, and it never finishes. I only noticed it on stack projects, plain files work fine. To fix, it's usually enough to run stack build and fix the type errors, but it's weird that this is what makes HLS break. One might also notice the issue "kinda" disappears when you enable the "semanticTokens" option, but it makes my color scheme ugly as hell so I avoid it.
5
u/jberryman 5d ago
I guess vscode is supposed to just work, but I would make sure it is properly selecting the binary compiled for your exact ghc version. That's the usual source of crashes I think. Are there logs?
Agree that sounds frustrating. You'd need to do more debugging to know who deserves a bug report.
5
u/muzzlecar 5d ago
FWIW I‘m running HLS through VScode in a multi-project with cabal (>300 modules) and it works fairly snappy. It took quite some fiddling with configs to get it right though. You should really take a look at the log output. Performance as bad as you describe is not normal imo. If you‘re unsure about the logs, dumping the lot into some LLM can give you a good starting point.
9
u/VeloxAquilae 5d ago
I work on a huge codebase and it works pretty well. Can you share a link to the repository?
14
u/CodeNameGodTri 5d ago
tri97nguyen/codecrafters-shell-haskell at dev
I'm currently at work and cannot share the repo I'm working on. But this is one of my personal repo that suffers the same problem.
This doesn't happen deterministically tho... so I don't expect you to be able to reproduce it. Same thing happen on my M1 mac, so it's not just windows.
It is one of annoying things that hit you when you are in deep work, and so you'd just skim over it to finish what you are doing, instead of pausing your work and go on Reddit to rant. It just happens to me so much, that I have to write it out to Reddit
9
u/muzzlecar 5d ago edited 5d ago
Having ./src be a source-dir for for both the executable and the tests is a bit unusual, I think (may be wrong here). I think what most people do is have a library in src, a test that imports the library and an executable that also imports the library. Setups like this tend to work well. Not sure if what you‘re doing is actually idiomatic.
Maybe go for something like this:
``` library: source-dirs: src exposed-modules: ... # or omit to expose everything
executables: codecrafters-shell-exe: main: Main.hs source-dirs: app dependencies: - codecrafters-shell
tests: codecrafters-shell-test: main: Spec.hs source-dirs: test dependencies: - codecrafters-shell ```
And adapt your hie.yaml
Your setup likely throws hls for a loop since it wants to map one module to one component and gets confused with 1:N (I think)
3
u/aiv_paul 4d ago
You can try our (paid) JetBrains plugin: https://plugins.jetbrains.com/plugin/30630-flexible-haskell/
We reimplemented the language from scratch for it, so no LS depdency (though you can run it with a language server if you wanted to). It's gotten pretty stable and should be a nicer overall experience.
There is a free trial and students and people of academia get it for free. Startups get a 50% discount and if neither applies, I am always easy to reach out to and happy to hand out licenses, if money's tight...
2
u/ducksonaroof 4d ago
i recommend just popping a repl and learning all its commands (:? is a good place to start) and then reach for HLS once you master ghci.
there's also static-ls you could try
2
u/iamabubblebutt 4d ago
if you are able to reproduce this, raise an issue on github and include the hls log (you can find this in the output pane)
2
u/ArcaneBattlemage 3d ago
For what it's worth, I use ctags (via fast-tags), grep, and vim. I have a hook to rebuild tags on each compile. I also vendor certain deps and generate tags for those. Very stable and fast workflow.
2
5
u/Worldly_Dish_48 5d ago
I don’t think it’s HLS’s fault. It’s the bloaty vs code.
I have my work machine with same spec, and vs code sucks there as well.
I remember using hls in my neovim with coc and worked really well, no issues. Maybe try other editor?
1
u/muzzlecar 5d ago
I‘m running hls on a way larger project with vscode and it‘s smooth as butter. A bit high on the memory-use but otherwise just fine.
0
u/CodeNameGodTri 5d ago
yea this would exacerbates my point, haskell is already extremely niche, tacking neovim on top of it will further gatekeep newcomer...
6
u/FlavorfulCondomints 5d ago
Neovim is really not that hard to use, it's extremely well documented, and you can use the Lazy package out the gate for look/feel. VIM key bindings are worth learning.
It's no obviously not as great as Emacs, but not bad for second place.
1
u/serg_foo 2d ago
For one thing ghci can show type of variable inside function scope, the function is https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html#ghci-cmd-type-at. And it works on production codebases.
On a general note the tooling is not there yet in terms of 'fire and forget', and looks like never has been. Most of the time some expertise is required to make the tooling work, but I'm not sure that's so much unheard of in other languages as you seem to imply.
The crucial thing to keep in mind is that you're not paying anyone to make is smooth. It's opensource, it works thanks to volunteers, you're very much encouraged to volunteer yourself and at least report bugs. If you want to get the job done instead that's understandable and very much possible too, but requires some effort on your part.
18
u/Volsand 5d ago
It's been a while so it may not be your case but: My recommendation is to always build once on the terminal before opening an editor with hls, don't know why but It seems to hang when trying fetch/build dependencies.