[ghostwriter]

> 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]

   > 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]

> 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)

[Zababa]

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.

[ghostwriter]

> Haskell is the only language where you seem to need Nix

that's not true, at least not in a larger context of available languages. There are C, C++, and a few other emerging language environments such as Mercury and ATS that can benefit from the same Nix toolchain right now, and their maintainers don't have to re-invent the wheel of packaging and distribution, as Nix solves that for them in a generic way.

> is basically a way to confirm "This language has some of the worst tooling I've ever encountered in my life."

For that you need to define criteria that allow you to identify the "worst" example. It is going to be the worst if you expect a monolith all-included distribution that has its own implementation of the same generic dev tooling approach (reproducibility, tracking of dependency sources, versioning etc), such as Rust Cargo or Go Modules. But these criteria won't match with the world where I see every software component to be a generic build instruction that Nix manages to provide regardless of the underlying language compiler.

[Zababa]

> that's not true, at least not in a larger context of available languages. There are C, C++, and a few other emerging language environments such as Mercury and ATS that can benefit from the same Nix toolchain right now, and their maintainers don't have to re-invent the wheel of packaging and distribution, as Nix solves that for them in a generic way.

Fair point, though Haskell seem to be the only language where Nix is the accepted solution to packaging and distribution.

> For that you need to define criteria that allow you to identify the "worst" example. It is going to be the worst if you expect a monolith all-included distribution that has its own implementation of the same generic dev tooling approach (reproducibility, tracking of dependency sources, versioning etc), such as Rust Cargo or Go Modules. But these criteria won't match with the world where I see every software component to be a generic build instruction that Nix manages to provide regardless of the underlying language compiler.

That's a reasonable point of view to have if you already know Nix. Most people don't, so they see Nix as Haskell-specific, except it's not and you now have to learn a general tool which usually takes way more time than learning Cargo or Go modules.

The point is that embracing Nix makes the learning curve of Haskell way steeper currently, especially when you also have GHC, Stack and Cabal. Maybe it will pay off in a few years when everyone uses Nix, but that's not the case today.

[tome]

> 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!

[ghostwriter]

> 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.

[tome]

> 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!