haskell-language-server VS hie-bios

The Haskell Language Server (LSP) always needs help: https://github.com/haskell/haskell-language-server/issues?q=...

As for GHC compile times... hard to say. The compiler does do a lot of things. Type checking and inference of a complex type system, lots of optimizations etc. I don't think it's just some bug/inefficient implementation, bc. resources have been poured into optimizations and still are. But there are certainly ways to improve speed.

> Haskell has an endemic problem where way too many development resources are put into fringe parts of GHC

There has been an incredibly amount of work put into all the things you mentioned over the last decade, which it sounds like you're unfamiliar with. https://github.com/haskell/haskell-language-server in particular is a pleasure to use in my experience. Package management is far from perfect, but it's always being worked on and I'll take it over anything in Python or the Node.js ecosystems any day. Developer experience has improved a lot since I started using the language and this is an area that the community and leadership absolutely cares about--I'd be surprised at anyone who spent time reading discussions in https://github.com/ghc-proposals/ghc-proposals or https://discourse.haskell.org/ or etc. would agree with you.

> Haskell has the worst support for records of all its peers. SML, OCaml, F# all have better records.

> Without good records it’s unreasonably hard to write large software projects.

> AFAIK it’s hard to retrofit ML-style structural subtyped records onto Haskell, because the type system is designed around that not being possible.

Haskell is not ML, and while Haskell records are weak they are not what is preventing people from writing big projects in Haskell. There is much more to the language than records. But I said this in my previous comment.

Nothing you've written resonates with me, and I've written Haskell and PureScript professionally as well as Java and JS along with a bunch of other languages that haven't been mentioned. I'm also actively working on an open source project in my spare time with thousands of lines of Haskell and PureScript code (https://github.com/ddellacosta/automation-service), not to mention a half dozen other random half-done projects and contributions I've made to other open source libraries and applications. What have you written in Haskell that has made you dislike it so much?

> Talk is cheap.

Yes it is.

The advent of language server protocol made possible the creation of HLS (Haskell Language Server), and there are plugins for many editors, such as vscode-haskell, that allow you to have auto-complete, auto-import, and automatic function signatures—also available to your editor of choice. The whole feedback loop of editing, compiling, and running is greatly improved.

HLS 2.3.0.0 is currently broken on Windows.

The Haskell community has been focusing on tooling and IDE support in the last several years. Haskell-Language-Server is a huge improvment, so the experience is probably much better than you remember, but it'll still be a while before it catches up with Rust.

static-ls is a low memory language server for Haskell that serves as an alternative to (hls)[https://github.com/haskell/haskell-language-server] with less functionality by using statically generated information. It is intended for (Highly recommend hls instead if you aren't having these issues):

You're likely going to have to set up a hie-bios file in an hie.yaml file. More info here: https://github.com/haskell/hie-bios

Look here: hie-bios (its the library used by haskell-language-server to get to know your project better, iirc).

Yeah the same happened to me with previous versions of the Haskell IDE Engine that used Stack, so I ended up with several snapshots under \~/.stack that took a lot of space. Nowadays I just install HLS, Cabal and a single HLS-supported GHC with ghcup. It's a huge difference. I think there is a Windows-supported equivalent of ghcup, but I have not used it. If you also have Stack installed, remember that you can place a [`hie.yaml`](https://github.com/mpickering/hie-bios#explicit-configuration) file in your project root that can [force HLS to use cabal](https://github.com/mpickering/hie-bios#cabal) instead of stack in your project (this was needed last time I checked, complex configurations would need tuning this file a bit, though).

You can provide an alternative stack.yaml to HLS, with the specific configuration for the ide, although you have to write down an explicit hie.yaml file, take a look to https://github.com/mpickering/hie-bios#stack

Please consider testing dev builds with the WIP new vgs-bios feature, inspired by the amazing hie-bios. It reads your project hie.yaml and supports multi-component/multi-package projects.