Deprecate ghcide tool and delete the VSCode extension

[pepeiborra]

Closes #935

[larskuhtz]

I am a happy user of the ghcide tool and I'd like to ask to not deprecate it.

I know that I am supposed to use the Haskell-language-server. Unfortunately, that's not an option for me. Just like hie in the past, it comes with too many features and dependencies that cause too much overhead to build and make them work in my development environment -- each time I tried it took me a long time to install it and get it to work and it would usually break soon due to dev-environment changes (like a new cabal or ghc version or other often non-obvious reasons).

What I like about ghcide is that it provides a non-opinionated set of basic IDE features. Those features cover everything that I need most (type checking, completion, jump to definition, show type) in a single easy to build, efficient, and robust tool. Haskell-language-server is adding features on top of it that I consider less important. Moreover many of the features the additional features of haskell-language-server seem opinionated to me. And they come at the price of a much more difficult to install and to use product.

[larskuhtz]

To reiterate, in my experience, ghcide is the first and only Haskell IDE tool (at least for vim) that just builds (even relatively quickly with a simple cabal install) and just works out of the box.

[ndmitchell]

@larskuhtz thanks for the feedback. It seems looking at your list of issues, the main two are:

• HLS is less GHC/Cabal/whatever changes compatible. Is this still true? It certainly was with HIE, but I was hoping HLS was less the case. Are there any specific dependencies that have caused you problems? Most of the GHC/Cabal compatibilities should be coming from hie-bios (which is shared) or GHC bumps (which are tested to the same versions with HLS and Ghcide).
• HLS takes longer to build. Do we have numbers on just how long? Would be useful information to have.
• Are there any other reasons you don't want to use HLS, but prefer Ghcide?

It may be that with some flags you can trim down HLS to very little over and above Ghcide (maybe you already can and we just haven't documented), or it may be that the work we've done means its no longer as problematic as it used to be.

[larskuhtz]

@ndmitchell I haven't used HLS yet. I tried to compile it using cabal v2-run ./install.hs --project-file install/shake.project hls. It failed with an TH related error for which it was not obvious to me how to fix it. ghcide builds with a simple cabal build on a plain ghc/cabal setup, which is a big plus for me. (To be fair, HLS actually failed while compiling ghcide, however when I build ghcide directly, I can just repeat the build and it passes on the second try. In the context of an HLS build that doesn't work).

HLS has dependencies that have been causing build issues in the past or would only build with patches, like for instance brittany. Overall the project structure of HLS is more complex and my experience tells me that projects of that kind tent to be fragile -- e.g. can take a longer time to be ported to new ghc versions. Ideally, an IDE tool should be available broadly across many different dev-environments, because I can't afford to switch or reconfigure my development tools for each project that I work on.

I understand that more advanced IDE tools provide a lot of value to teams working in relatively homogeneous and stable environments where it pays off to spent the extra time to setup and maintain those tools. But I also think that its desirable to have tools that are focused on common basic needs and just work everywhere with little dependencies. To me it seems that HLS belongs to the former while Ghcide belongs to the latter category of tools.

So, I don't want to argue against HLS -- I will continue to try it and gladly use it if it works for me. I just like to continue to use ghcide, at least as a fallback solution that is available when HLS isn't.

[jneira]

@larskuhtz i agree with almost all arguments.
I think @pepeiborra plan is to slim down hls to get a version with lot less dependencies, see haskell/haskell-language-server#647 (comment)
That said, i think we will keep ghcide executable at mid (long?) term to use it in ghcide tests.

It would be great to open an issue in hls about your failing install but i want to note there are precompiled executables for all major os's and supported ghc versions that make you not need to even compile it: https://github.com/haskell/haskell-language-server/releases/tag/0.6.0

[pepeiborra]

Exactly. As a user, you want to have a small ide with few dependencies. I want the same thing!

But as discussed in #936 as a maintainer I want to break down some of the monolithic completions code into multiple providers using the nice plugin model in HLS. Thus it seems natural to move this out of ghcide and into an HLS plugin.

These two desires should not be in opposition.

1. We need to make improvements to the HLS project definition and build system so that it's easy to select and build only a subset of the plugins.
2. And we need to get the current ghcide users onto HLS so that we can move the completions and other code without impacting them.

This PR is to get 2 in motion, and before merging I will add a link to this discussion for anyone interested in why we are doing this.

[larskuhtz]

I think @pepeiborra plan is to slim down hls to get a version with lot less dependencies

That would be great, too, if HLS would be modular in a way that a build would just ignore dependencies that one doesn't care about or that might be less stable. What I really like about ghcide is that it "just builds" and "just works" with a vanilla ghc dev environment.

In any case my comments are meant as a compliment for ghcide and not criticism of hls.