stack VS haskell-language-server

Ah, didn't run into this issue, as I don't use vscode.

Apparently there is some work being done to improve the stack <> hls experience, but I wouldn't know how it's going and when it's being delivered: https://github.com/commercialhaskell/stack/issues/6154

Fix incorrect warning if allow-newer-deps are specified but allow-newer is false. See #6068.

See https://haskellstack.org/ for installation and upgrade instructions.

Fair enough! Thanks for the suggestion, then. In fact, the non-Python language I develop most in (Haskell, with the Stack package manager) has exactly that behaviour as a default: new packages are installed to a sandboxed local directory, and it takes an explicit request to install something globally. (And even then, you can switch between different global "known good configurations" of package versions which work well together – a pretty handy feature.)

In YAML configuration files, the hackage-security key of the package-index key or the package-indices item can be omitted, and the Hackage Security configuration for the item will default to that for the official Hackage server. See #5870.

See https://haskellstack.org/ for installation and upgrade instructions.

Yes, that is correct. Stack's allow-newer: true configuration has always actually meant 'ignore bounds'. However, the author of the allow-newer-deps development has in mind a further development that will introduce an actual ignore-bounds key with the same expressive syntax that is used by Cabal. This is discussed at Stack #5910.

You can download binaries for this pre-release from: Release rc/v2.9.2.1 (release candidate) · commercialhaskell/stack · GitHub.

I'm trying to use the cabal mixins feature to automatically replace every implicit prelude import with a custom prelude (in this case relude). apparently it doesn't play well with `stack repl` https://github.com/commercialhaskell/stack/issues/5077 but I don't really use it anyway.

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):

Indeed, there is a lot of room for improvements. But I just wanted to acknowledge and thank the work of those involved in HLS which IMHO was a game changer in that regard.

Specifically, gchup and HLS are both opensource community efforts. If you want to see HLS work with ghc-9.2.5, you may want to ask https://github.com/haskell/haskell-language-server or, better, provide them a PR that builds HLS with ghc-9.2.5.

Sadly ghcup tui is not available on windows, but you can check the available versions with ghcup list. Hls lists the compatible versions of ghc at their github releases. For 1.8.0.0 I went with 9.4.2. To install it and set it to default you have to use the ghcup install ghc 9.4.2 then the ghcup set ghc 9.4.2. Hopefully this will be useful to someone with the same problem.

Here's an issue I created for it: https://github.com/haskell/haskell-language-server/issues/3348

The code is executed by HLS, see https://github.com/haskell/haskell-language-server/blob/master/plugins/hls-eval-plugin/README.md and then its markdown/html output is displayed by VS Code.

As you can see there, Shake is also a good fit for Cabal scripts. And Cabal scripts work better in 3.8. There are still issues loading them with HLS, but hopefully not for long. For this reason, I also have a build.sh which wraps that, allowing the script to be loaded via GHC directly, but I look forward to being able to remove this.