46 ms·

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 th

by _se 5y ago

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.

gavinray 5y ago
> 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 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-of-delphi-code-compiled-in-5-minutes-on-16-cores/ 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. Oh no, I purposefully left all of the concrete complaints and details out. 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."
- ghostwriter 5y ago
  > 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.
  - gavinray 5y ago
    > 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 contribute, via publishing configurations and other things. 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.
    - ghostwriter 5y ago
      > 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/distributed-builds.html 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 https://github.com/input-output-hk/haskell.nix)
      - Zababa 5y ago
        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.
- zarzavat 5y ago
  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.
- throwaway81523 5y ago
  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.
  - Zababa 5y ago
    > 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.
- Zababa 5y ago
  > 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?
tome 5y ago
Experience reports are extremely valuable to the Haskell community so it's helpful to the community to encourage rather than discourage them!

by _se 5y ago

gavinray 5y ago

> 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 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-of-delphi-code-compiled-in-5-minutes-on-16-cores/ 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. Oh no, I purposefully left all of the concrete complaints and details out. 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."

ghostwriter 5y ago
> 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.
- gavinray 5y ago
  > 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 contribute, via publishing configurations and other things. 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.
  - ghostwriter 5y ago
    > 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/distributed-builds.html 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 https://github.com/input-output-hk/haskell.nix)
    - Zababa 5y ago
      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.
zarzavat 5y ago
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.
throwaway81523 5y ago
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.
- Zababa 5y ago
  > 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.
Zababa 5y ago
> 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?

tome 5y ago

Experience reports are extremely valuable to the Haskell community so it's helpful to the community to encourage rather than discourage them!