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.

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

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.

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