Live data from Hacker News

2021 State of Haskell Survey

haskellweekly.news

11–20 of 23 posts

Re: 2021 State of Haskell Survey

#11
post #2

This language has some of the worst tooling I've ever encountered in my life. I could go on and write you novels about it, and if someone really wants to know I can provide a massively detailed, exhaustive list with logs, screenshots, Github issues, etc. But sweet jesus, you'd think in 2021 a basic tenet of a language would be: "I want autocomplete + hover-docs to work on a project which has +50 dependency libraries…

> despite Haskell being ~31 years old.

Tbf I think things are worse now than a few years ago because of the explosion of new Haskell code, plus the resulting several somewhat conflicting re-imaginings of the tooling to deal the increased complexity of juggling the now-huge code corpus. Stack, the original cabal, the current different cabal, Haskell Platform, etc. I like to think the vigorous activity in this area is not entirely unhealthy, since it is about identifying and attacking real problems. But, for those of us not in the middle of it and just want something that works, it is somewhat painful.

Tome, I can write up some issues and email them to you, but basically we need a better out-of-box experience. "stack ghci" takes so long to start up on an HDD server (tons of stuff getting paged in) that I keep thinking it has simply hung, while the old ghci was nowhere near that slow. Emacs Haskell mode goes into some crazy error loop if you try to use a ghci subprocess window (that used to work great). Haskell Platform (a blessed set of packages, more or less) was a good idea in principle but I think it became unmanageable and stopped being maintained.

I haven't done anything with Haskell in a while and this kind of thing is the main obstacle. Command-line ghc (ok, stack ghc) still works so it is still possible to compile stuff less conveniently when required. Mostly though, I just use other languages. If I were using Haskell for daily work then I could probably reach some reasonable tooling setup with enough effort, but as an occasional user it just hasn't been worth it.

Re: 2021 State of Haskell Survey

#12
post #4
post #3

Earlier quoted context omitted.

Been working perfectly for me since 2018. Ymmv I guess? Not sure why you'd take that attitude though, really not a great way to get across whatever point you think you have other than that you can rant.

> Not sure why you'd take that attitude though, really not a great way to get across whatever point you think you have My point is that Haskell is older than I am, and still hasn't figured out to produce a decent developer experience. I guess to fail to understand how if the language is as fantastic as it's made out to be, why there's no equivalent to rust-analyzer or Eclipse jdt.ls and it can't build my company's 50…

If you want to code in Pascal, you know where it is. Pascal was designed for fast, one-pass compilation, and its compilers don't have to do nearly as much work as Haskell compilers or even C compilers. Of course you could go even further and use Forth, but then you are doing even more work manually that the compiler could be doing for you.

GHC's compilation speed is in the same category as G++, which isn't great, but we users are mostly used to it, and deal with it by standard methods like separate compilation.

Some of the other issues you mention (such as crashes) are more significant, while some (IDE integration) are mostly a matter of the hardcore users not caring that much. I'm not that hardcore myself, but I was satisfied with Emacs Haskell mode until it broke a few releases ago, and even now it's fine for editing Haskell code, just not for running it inside the editor.

Re: 2021 State of Haskell Survey

#13
post #4

Earlier quoted context omitted.

> Not sure why you'd take that attitude though, really not a great way to get across whatever point you think you have My point is that Haskell is older than I am, and still hasn't figured out to produce a decent developer experience. I guess to fail to understand how if the language is as fantastic as it's made out to be, why there's no equivalent to rust-analyzer or Eclipse jdt.ls and it can't build my company's 50…

If you want to code in Pascal, you know where it is. Pascal was designed for fast, one-pass compilation, and its compilers don't have to do nearly as much work as Haskell compilers or even C compilers. Of course you could go even further and use Forth, but then you are doing even more work manually that the compiler could be doing for you. GHC's compilation speed is in the same category as G++, which isn't great, but…

> If you want to code in Pascal, you know where it is. Pascal was designed for fast, one-pass compilation, and its compilers don't have to do nearly as much work as Haskell compilers or even C compilers.

OCaml is at a good spot between Pascal and Haskell for that. Compared to Haskell, I find the tooling easier to understand but maybe not easier to use at first.

Re: 2021 State of Haskell Survey

#14
post #8
post #2

This language has some of the worst tooling I've ever encountered in my life. I could go on and write you novels about it, and if someone really wants to know I can provide a massively detailed, exhaustive list with logs, screenshots, Github issues, etc. But sweet jesus, you'd think in 2021 a basic tenet of a language would be: "I want autocomplete + hover-docs to work on a project which has +50 dependency libraries…

> I could go on and write you novels about it, and if someone really wants to know I can provide a massively detailed, exhaustive list with logs, screenshots, Github issues, etc. Hello, yes, I really want to know! I am on the board of the Haskell Foundation and improving developer tooling is likely to be one of our focus points in the near future. User experience reports will help us make progress. My email address i…

It's very nice to know that people with the right attitude are in the Haskell Foundation.

Re: 2021 State of Haskell Survey

#15
post #7

Earlier quoted context omitted.

> I guess to fail to understand how if the language is as fantastic as it's made out to be, why there's no equivalent to rust-analyzer or Eclipse jdt.ls and it can't build my company's 50MB binary in less than half an hour. And why is this state of affairs tolerated for decades? You fail to understand that this is your personal experience based on the approaches you've chosen to apply. I have no problems with HLS, VC…

> I have no problems with HLS, VC Code, and Cabal, everything works seamlessly. So do I -- until I try to use them on massive, realworld projects. > You fail to understand that this is your personal experience based on the approaches you've chosen to apply. First off -- I can't write Haskell. I only think all of this because of time working on tooling trying to make it easier for other people that DO write Haskell to…

> You've never compiled GHC from source? How long does that take on your machine?

I have, but the point is that I don't have to, because there are transparent distributed builds in Nix that I utilise when I want to compile something big, as you say "real-world", fast. I split software into many small self-contained packages and delegate the work of compiling it all to remote machines configured for faster compilation times, and then I just pull complete binaries onto my laptop (https://nixos.org/manual/nix/unstable/advanced-topics/distri...). Subsequent changes in smaller packages are rebuilt incrementally.

My point and the answer to your question ("And why is this state of affairs tolerated for decades?") is that GHC doesn't have to implement its own version of dev environment bootstrapping, distributed builds and other niceties as part of their core tooling, because it's already solved on other level of dev-infra tooling, they can just provide links to working solutions and explain them, for instance haskell.nix (https://github.com/input-output-hk/haskell.nix)

Re: 2021 State of Haskell Survey

#16
post #10

Earlier quoted context omitted.

> I guess to fail to understand how if the language is as fantastic as it's made out to be, why there's no equivalent to rust-analyzer or Eclipse jdt.ls and it can't build my company's 50MB binary in less than half an hour. And why is this state of affairs tolerated for decades? You fail to understand that this is your personal experience based on the approaches you've chosen to apply. I have no problems with HLS, VC…

> You fail to understand that this is your personal experience based on the approaches you've chosen to apply. Indeed it is, and learning more about users' experiences based on the approaches they've chosen to apply will help us make Haskell tooling more reliable in the future. These kinds of experience reports should be encouraged so that we can address the difficulties that they explain!

> These kinds of experience reports should be encouraged so that we can address the difficulties that they explain!

sure, my reply to OP was an experience report too, where I feel confused that people are still struggling with topics I've almost never experienced since after switching to Nix. They suggest it's a fault on GHC side, I suggest it's not a fault on GHC side, as there's already a solution implemented on another level of dev tooling that covers the mentioned issues (bootstrapping, discoverability, (re-)compilation times, binary sizes) for GHC in a true generic Unix way.

Re: 2021 State of Haskell Survey

#17
post #4
post #3

Earlier quoted context omitted.

Been working perfectly for me since 2018. Ymmv I guess? Not sure why you'd take that attitude though, really not a great way to get across whatever point you think you have other than that you can rant.

> Not sure why you'd take that attitude though, really not a great way to get across whatever point you think you have My point is that Haskell is older than I am, and still hasn't figured out to produce a decent developer experience. I guess to fail to understand how if the language is as fantastic as it's made out to be, why there's no equivalent to rust-analyzer or Eclipse jdt.ls and it can't build my company's 50…

> Pascal/Delphi had an IDE and Dev UX that, according to programmers old enough to have used it, surpasses the productivity of most modern tools.

I wonder if this is really true. If it is, why wouldn't people use it?

Re: 2021 State of Haskell Survey

#18
post #7

Earlier quoted context omitted.

> I have no problems with HLS, VC Code, and Cabal, everything works seamlessly. So do I -- until I try to use them on massive, realworld projects. > You fail to understand that this is your personal experience based on the approaches you've chosen to apply. First off -- I can't write Haskell. I only think all of this because of time working on tooling trying to make it easier for other people that DO write Haskell to…

> You've never compiled GHC from source? How long does that take on your machine? I have, but the point is that I don't have to, because there are transparent distributed builds in Nix that I utilise when I want to compile something big, as you say "real-world", fast. I split software into many small self-contained packages and delegate the work of compiling it all to remote machines configured for faster compilation…

Haskell is the only language where you seem to need Nix. That alone make a big difference for people trying to get into Haskell. I'd say it's also the only language where you seem to need dev-infra tooling. I can see how using Nix helps, but saying that "it's already solved on other level of dev-infra tooling" is basically a way to confirm "This language has some of the worst tooling I've ever encountered in my life.", which was the initial assertion.

Re: 2021 State of Haskell Survey

#19
post #10

Earlier quoted context omitted.

> You fail to understand that this is your personal experience based on the approaches you've chosen to apply. Indeed it is, and learning more about users' experiences based on the approaches they've chosen to apply will help us make Haskell tooling more reliable in the future. These kinds of experience reports should be encouraged so that we can address the difficulties that they explain!

> These kinds of experience reports should be encouraged so that we can address the difficulties that they explain! sure, my reply to OP was an experience report too, where I feel confused that people are still struggling with topics I've almost never experienced since after switching to Nix. They suggest it's a fault on GHC side, I suggest it's not a fault on GHC side, as there's already a solution implemented on an…

> my reply to OP was an experience report too

Thank you for yours too. I'm glad you're having a good experience with GHC and Nix. I haven't taken the Nix plunge yet!

Re: 2021 State of Haskell Survey

#20
post #8
post #2

This language has some of the worst tooling I've ever encountered in my life. I could go on and write you novels about it, and if someone really wants to know I can provide a massively detailed, exhaustive list with logs, screenshots, Github issues, etc. But sweet jesus, you'd think in 2021 a basic tenet of a language would be: "I want autocomplete + hover-docs to work on a project which has +50 dependency libraries…

> I could go on and write you novels about it, and if someone really wants to know I can provide a massively detailed, exhaustive list with logs, screenshots, Github issues, etc. Hello, yes, I really want to know! I am on the board of the Haskell Foundation and improving developer tooling is likely to be one of our focus points in the near future. User experience reports will help us make progress. My email address i…

Wow, very surprising answer.

Will genuinely take you up on this, and try to condense things into an easy-to-read list =)

Post reply on HN