Fair enough, though I’ll note that only I’ve given an up-to-date reference.

Stack vs Cabal was a huge argument where I worked with multiple teams using different build tools. Add Nix and nix2whatever, and it was more fun. Spent half my time debugging build instructions

It is not that much better in Java land. Getting builds right takes lots of resources, keeping new and old things running is not trivial.

I haven't had that experience for newer code bases. Yes, there's some ancient "works only in my IDE" stuff but that's really not how modern Java is written.

Yes, there is a disagreement about whether to use maven or gradle, but IMHO they both work reasonably well out of the box.

In my experience, if you have to build an older maven project, you have to go through a lot of painful hoops, mostly around HTTP vs HTTPS repos and java source/compiler versions. I have encountered many old projects that don't build out of the box, and of those, I've only managed to get about half working.

Right now, things are pretty good. But this is surprisingly recent. Gradle and Maven have both been good at managing dependency versions for a long time. Gradle has also been good at managing the Gradle version, via the wrapper, for a long time; Maven has equivalent wrapper now, but it's quite new, and support in the wider ecosystem is patchy (eg a TeamCity Maven build step can't use a wrapper, i don't think). Meanwhile, there is no standard way to manage JDK versions; there are SDKMAN! and asdf, and they work fine, but they aren't de facto standards. Gradle lets you specify the JDK version to build with via toolchains, but this is quite new (6.7 in 2020). I have no idea if Maven has an equivalent.

While what you say is true, the point about the JDK versions is mitigated a bit by the fact many things are backwards compatible. Although yes, if you jump from 8 to 17, you're going to run into some problems.

I'm not a huge fan of the gradle toolchain tool (I don't think gradle should be managing my JDKs and I would prefer if it could instead just fail the build if you use the wrong JDK version), but I do understand why it exists.

Yes. I've been in teams where there has been gradle vs maven arguments.

Right now the Mac (M1 or M2) users in our team can't run our integration tests. It has been suggested that if we migrate our 50-100 services to Java 17 then the tests will work for them again. Trying to do this breaks the Gradle scripts, and the errors are so vague I can't tell why it's complaining.

While I understand what you're saying, the "XY doesn't work for mac users on M1/M2" is a really pervasive problem across all technologies.

In that same thread that you've linked, other people have later replied arguing for why they prefer Stack so... I don't really think that you've given an argument that is persuasive enough to someone who is new to Haskell.

(And I'm not even that new to Haskell. It's just that I don't use it every day and when I come back to it and have to remember the weird incantations and dances I have to perform to make HLS not crash or want to overwrite my stack-installed Haskell version, I'm usually rather annoyed.)

> In that same thread that you've linked, other people have later replied arguing for why they prefer Stack so...

I merely stated that I have no trouble running old projects using stack.

> I don't really think that you've given an argument that is persuasive enough to someone who is new to Haskell.

Honestly, cabal improved a lot since the old ages. For a beginner, either stack or cabal should be very fine imo.

> or want to overwrite my stack-installed Haskell version, I'm usually rather annoyed.

Not sure why you would want to do that. Either you use stack and let it handle your ghc install, or you don't, and I really don't see why you would use stack only for compiler install.

> I merely stated that I have no trouble running old projects using stack.

I was referring to the linked forum thread.

> Not sure why you would want to do that. Either you use stack and let it handle your ghc install, or you don't, and I really don't see why you would use stack only for compiler install.

What I mean is that when I start VS Code on my Haskell project again after a couple months, it tells me that it needs to donwload a new version of GHC. And I don't know why since I didn't change anything about my project. And when I try to click on update, it fails and the HLS extension crashes. I can't tell you where exactly this goes wrong, but it's obvious that these tools don't all work well together.

edit: Now I see that my wording was confusing. You quoted me as saying that I want HLS to overwrite my GHC version, but what I meant was that I want to prevent HLS (actually, I should have said the VS Code Haskell plugin) from doing that. The subject of "want" in that sentence you quoted is "HLS".

Ah, didn't run into this issue, as I don't use vscode.

Apparently there is some work being done to improve the stack <> hls experience, but I wouldn't know how it's going and when it's being delivered: https://github.com/commercialhaskell/stack/issues/6154

You posted a link to a forum. The official Haskell language "get started" page says to use both: https://www.haskell.org/get-started/

It's listed after Cabal as an "alternative", so a lot of people will presumably ignore it if they don't see any reason why they'd want anything else.

I personally wish that page were even more opinionated, but it's politically tricky.