2021 State of Haskell Survey
haskellweekly.news
2021 State of Haskell Survey
1–10 of 23 posts
Re: 2021 State of Haskell Survey
#2This 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 and several hundred files."
The language may be the best thing since sliced bread, but the tooling/ecosystem and authorship process is absolutely the worst thing I've ever touched.
Here's a particularly funny one:
https://user-images.githubusercontent.com/26604994/139553801...
Even "experimental" languages like Nim and Zig had a more reliable and easier to use tooling and IDE integration than Haskell did (for me), despite Haskell being ~31 years old.
Re: 2021 State of Haskell Survey
#3This 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…
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.
Re: 2021 State of Haskell Survey
#4This 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…
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
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?
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. And it is capable of compiling a billion lines of code in a couple of minutes.
https://www.fmxexpress.com/ryzen-9-5950x-one-billion-lines-o...
So what is up with Haskell?
"Ymmv I guess" isn't what I would call a sound approach to core language tooling.
> other than that you can rant.
Unless someone wants to. Then I can dump a wall of particular things that are broken.
See: "and if someone really wants to know I can provide a massively detailed, exhaustive list with logs, screenshots, Github issues, etc."
Re: 2021 State of Haskell Survey
#5Earlier 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…
> 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 Code, and Cabal, everything works seamlessly. I use Nix to bootstrap everything, I split my software into smaller packages so that I benefit from distributed, incremental, and cached Nix builds, and my statically linked binaries rarely exceed 10 Mib after UPX. I couldn't care less whether it's part of Haskell distribution, because the same language-independent toolchain I use in several different stacks works for GHC too. I'd rather let GHC maintainers work on compiler and language features than expected them to re-invent Nix functionality for the sake of it being part of the compiler distribution.
Re: 2021 State of Haskell Survey
#6Earlier 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…
Haskell is not meant to be used to construct software. It's meant to be used to construct papers that might be used by people who want to make languages to construct software.
Re: 2021 State of Haskell Survey
#7Earlier 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…
> 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.
> You fail to understand that this is your personal experience based on the approaches you've chosen to apply.
Sometimes you don't get to make the choices, and you're stuck with someone else's architecture decisions and a team + community of people doing the best they can with them.
You've never compiled GHC from source? How long does that take on your machine?
The moment someone gets a codebase that has hundreds/thousands of files working with proper language server diagnostics in an IDE with +24 hours uptime (like every other production-grade language) I will eat my shoe.
Re: 2021 State of Haskell Survey
#8This 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 is in my profile (https://news.ycombinator.com/user?id=tome).
Re: 2021 State of Haskell Survey
#9This 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…
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.
Experience reports are extremely valuable to the Haskell community so it's helpful to the community to encourage rather than discourage them!
Re: 2021 State of Haskell Survey
#10Earlier 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…
> 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!