A semester of Haskell-language-server: an internship report | Hacker News Reader

A semester of Haskell-language-server: an internship report

tweag.io

62 pointsruneks32 comments

Sadly the state of LSP's Wingman (hls-tactics-plugin) is somehow typical for Haskell. This LSP plugin has been responsible for things like case splits (automatically filling out all branches of a `case` expression). It does not work with GHC >= 9.2 because of changes in GHC's `exactprint API` - the problem is adding the generated source in the AST to get the correctly formatted source code into the text editor. GHC does _actually_ move fast and breaks tooling related things (not "old" source code, they are wary of that).

Conclusions:

    I've been AFK from HLS development for a few months. Let me give you my status.

    I do not find myself excited to work on GHC-related refactoring tools. I personally find that the stability and quality of the ghc-exactprint API has made it unpleasant for me to work on new refactoring tools.

    Alan Zimmerman has done absolutely fantastic work on the ghc-exactprint API, and the effort is genuinely leviathan. I'm not exaggerating - it's a mind-boggling amount of work.

    However, the result is still not easy enough to work with (for me) to make me want to work on it. I had a massive amount of energy and spent well over 60 hours on tactics and code actions. And by the end, I realized I could not trust that a future version of GHC wouldn't simply break all of it again.

https://github.com/haskell/haskell-language-server/issues/35...

Original issue: https://github.com/haskell/haskell-language-server/issues/29...

As a rule of thumb, I find that the quality of a language’s LSP server is strongly indicative of how suitable that language is for a serious software project.

If you’re curious about what that means for Haskell, try opening a Haskell project, starting LSP, and hovering a few variables while watching the HLS process’s memory usage.

What would you say to people like me who never ever use LSP regardless of language? I think a team of people with my workflow (plain emacs and a repl) could build and serious software projects successfully. So maybe LSP isn't the be-all end-all in that department?

I don’t think GP’s point was that you have to use an LSP server to write serious projects. Rather, the quality of LSP support is rapidly becoming a good proxy for the overall state of tooling for a language (and, arguably, good tooling is a good indicator of suitability for large projects)

That out of the way, I would suggest that you do give LSP a try. The beauty of LSP is that it doesn’t care what editor you’re using, so you can just use lsp-mode and get going.

What makes something suitable? The tooling and language servers around Python are atrocious, but it is nevertheless very widely used (including among academics, arguably one of the more serious fields. Of course it also generally produces absolutely garbage code, but I don't think that's the tooling's fault).

Oh I have tried it. I didn't use it much, and it made it even more clear that the minutiae of reading and writing code is nowhere near a bottleneck.

Of course it’s possible to be effective with different tools but I find even Emacs is made a lot better by Flymake/Flycheck and Eglot.

I like the fzf and rg integration. And some custom elisp (especially for codegen).

i usually don’t use LSP myself most of the time, it’s just a heuristic.

in $current_year, LSP is considered an important part of a language’s ecosystem.

if there are glaring issues with it, something is seriously wrong- maybe the language itself has performance issues, or tiny userbase, etc.

I would say Haskell LSP is considered unimportant by a nontrivial amount of Haskellers. I know of many who just don't bother using it at all. So in the Haskell community, LSP is less important than LSP is in other language communities.

Don't know why this is getting down voted, I've drawn a similar conclusion.

If a language has a rock solid and performant LSP implementation, it says a lot about the current status and culture of that language with regards to its capacity as a professional-grade general purpose programming language.

Can you elaborate? On the one hand it's obviously true. On the other hand, because it's so obviously true, it's content free. One might as well say "If a language has a

* rock solid and performant compiler/interpreter

* rock solid and performant VM/run time system

* rock solid build tool

* large and helpful community

* wide array of free learning resources

* pragmatic approach to balancing new features with stability

it says a lot about the current status and culture of that language with regards to its capacity as a professional-grade general purpose programming language".

I'm a member of the Haskell community who takes an active interest in making Haskell more accessible for production use, so I'd be interested to know reasons, if any, we should prioritise the development of haskell-language-server above other parts of the ecosystem.

> Can you elaborate?

> I'm a member of the Haskell community who takes an active interest in making Haskell more accessible for production use, so I'd be interested to know reasons, if any, we should prioritise the development of haskell-language-server above other parts of the ecosystem.

Thank you for your response, I'll do my best!

It's not that a great LSP implies anything, rather that the inverse does; if a language (or its community) declares itself as professional grade, comparisons with other professional grade languages are inevitable.

The LSP is the second impression one gets are first installing the language and setting up a new project, and it's probably the most used tool in a day-to-day experience with the language; you spend more time navigating and reading code than compiling it (if not, my condolences).

If I pick Go or Zig (which is in beta), I get the following out of the box:

* Quick installation

* Easy integration into my existing code editor

* Full blown, blazingly fast LSP even if I'm on dinosaur equipment

* First code compiled and ran within minutes of downloading the first binary

Compared to your average functional programming language experience:

* Finicky installation on some systems, and/or not available on all systems

* LSP is available, but is either semi-complete, broken between versions, slow and/or expensive

* First compile often requires some compilation of the language/std itself, which can take minutes, or it fails with opaque errors in some dependency I don't know about

Some combination of above has been true for me with Erlang, Elixir, Clojure, OCaml, F#, Elm and Haskell. I'm a sucker for and love all these languages, but unfortunately most of them don't hold a candle (with regards to my previous points) to most other languages.

I want to emphasize that I prefer functional languages and use one or more daily (Clojure at work, Elixir and OCaml for fun), this is not a stab at them, merely a general observation.

I've been writing a lot of OCaml lately and I'm impressed with the state of its LSP and development experience. I've had no issues with the LSP, dune works great. Having to use both opam and dune is a bit confusing, but it gets the job done.

I agree! OCaml is one of the best of the bunch, and it appears to be improving all the time. Looking forward to see what the future brings.

Lots of actionable info there, thank you! I appreciate it, fredrikholm.

How do you define "quality"? For example, `rust-analyzer` (the Rust LSP) is deliberately buggy, with features being added even if they don't yet handle all edge cases. If one feature crashes, it's no big deal and the rest of the server continues to operate. The reasoning is that occasional wrong completions are not a critical issue; for the specific use-case of an LSP, it's better to have more features.

In this case I personally define "quality" as how well the language LSPs do their job without getting in my way. Haskell's would often crash, have lots of weird issues, and use insane amounts of memory that would force me to bounce the server periodically.

I've heard about Rust's LSP being buggy, but I had great success with it when I used it in a project. It gave a lot of useful suggestions and linting in relatively complex situations so it's understandable that it would have a hairy edge cases. But I never really saw them in personal usage, which was a very different experience from HLS.

So my personal impression of rust-analyzer was "high quality", and HLS less so.

It's an extremely accurate proxy for commercial baking, so if you thing any language without a commercial entity behind it isn't serious, yeah, you'll get that conclusion.

But I find that people that think like that are just swimming through tons of publicity and unable to make their way through it.

Commercial backing does mean a language is significantly more likely to be usable in my opinion, but it's not a requirement: off the top of my head there's exceptions Racket, Lua, and Clojure (I'm not sure this counts as I don't really know how much Cognitect invests into maintenance).

Clojure is still technically owned by Rich Hickey. Changes to Clojure are ultimately on his time and approval. With that said, both Clojure and Datomic are both worked on daily by Cognitect employees. Nubank in particular has a lot of interest in supporting Datomic development since it is a critical piece in their infrastructure. (Allegedly, Nubank acquired Cognitect because of how important Datomic development is to them). Just because Clojure is slow to make changes to the core language doesn't mean it's not corporate backed. Moreover, Cognitect sells consulting services for Clojure and Datomic, and they sponsor dozens of open source developers. Most notably for this thread, maintainers of Calva (VS Code plugin for Clojure), the maintainer of clojure-lsp, and the maintainer of clj-kondo (static analysis tool used by clojure-lsp).

There's also other consultancies I can think of that make non-trivial efforts to foster a community around the language. Gaiwan has Lambda Island as a subsidiary that publishes video tutorials, hosts the ClojureVerse Q&A forum, and has dozens of open source libraries under the "Lambda Island" organization on GitHub, with active maintenance by Gaiwan employees. Then there's Juxt, which does more consulting than open source, but they have their own open source software (like XTDB) and libraries, which are also maintained by employees of the company. But personally, I think the dozens of individuals that Cognitect sponsors through GitHub is enough evidence for corporate backing of the language, considering who they sponsor end up spanning a vast majority of libraries and tooling that Clojure developers use every day.

That makes sense, thanks for sharing. The Clojure community really knows how to do more with less.

TIL that C cannot be used for serious projects

C support in Visual Studio Code is pretty good, I’ve found.

Not at all in my experience, extremely laggy and resource hungry, not even mentioning incorrect multiple times

clangd is pretty good

Sadly, Ive lost enthusiasm for Haskell years ago.

Me too. I'm a very experienced dev and solidly competent in Haskell. In the end, Haskell and its ecosystem was a horrible time-sink. Bottom line: I get far more accomplished elsewhere.

Good riddance Haskell.

For the sake of discussion, would you mind describing why? Is it because of poor tooling, or something else?

At the time I was learning Haskell it didn’t have structs I think and there were many different extensions of Haskell. Also I always got the sense it was an academic language and articles discussing it were very advanced and hard to read and just not applicable to my problems. And the code was very terse and hard to read.

Haskell didn't have structs? What could you possibly mean by this?

Might be https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/over...

Reply on news.ycombinator.com