cabal init should include common options with GHC options, with -threaded and "with-rtsopts=-N" by default.

[liamzee]

Describe the feature request
cabal init should enable a common options field, which is keyed to be picked by default, and that should include ghc-options: -threaded "with-rtsopts=-N4" by default.

Additional context
Just thinking, but figuring out how to get cabal to implement multiprocessing takes a bit of Google time (I've done it before, but this time it took me about 90 minutes to figure out how to get it working).

Having multiprocessing on by default increases convenience, and helps if, say, others in the community who teach, might be interested in teaching Haskell concurrency early on.

Implementation Plan

If accepted, give me about 2 weeks and I'll take care of it.

[georgefst]

Hopefully this will just be made the default in GHC. In which case, I'd vote against cluttering Cabal files with a flag which will soon have no effect.

I don't know whether there's anything blocking the GHC change?

[liamzee]

@georgefst
Currently, this is waiting on upgrades to GHC test suites, and there is no current implementer on the GHC feature.

Even if -threaded is rendered redundant, "with-rtsopts=-N" won't, because the rtsopts aren't being set on by default.

And even if -N becomes default to GHC-compiled programs, having a common options field with ghc-options: is convenient for new learners, as you can say, if you wish, set -O2, -O, or -O0 as needed.

[andreabedini]

This should be a GHC default and I think cabal should not insert ghc-options: by default.

[chreekat]

I'm in favor of the change to cabal init. If in ten years it becomes redundant for the three most common versions of GHC in use, it can be removed without breaking anything.

[georgefst]

I think cabal should not insert ghc-options: by default

That ship has actually already sailed with -Wall.

[geekosaur]

There's a bigger problem, though: GHC has -rtsopts because there may be security (e.g. DoS) reasons why these options should not be exposed by default. This would defeat that.

[liamzee]

@geekosaur

Could you provide more information on that? Or should we consult GHC specialists / GHC team on what features are unsafe?

@andreabedini

If you check the status of -threaded on GHC, it seems as though the project is extremely stalled due to difficulty certain people are having with tests.

I think this is primarily a newbie issue; i.e, more experienced Haskellers know how to set the options themselves, but for people coming into Haskell, when they get told to use cabal init, will they end up with a threaded program by default?

This also provides the potential for users to get into Haskell concurrency quickly, which is also, ummm, rather aligned with relatively imperative code. While unfortunate, this does help onboarding for new users... although in my limited experience, imperative Haskell can quickly end up being off-putting to beginners (it's not that much better than true imperative languages); the weirdness is what keeps people in.

---

As of right now, I'm proposing -threaded "with-rtsopts=-N4" as a default, since as Artem, iirc, pointed out in IRC / Matrix, GHC's parallel GC starts to eat up performance on with-rtsopts=-N on 16 cores or more.

[geekosaur]

https://downloads.haskell.org/ghc/9.8.1/docs/users_guide/phases.html#ghc-flag--rtsopts[=%E2%9F%A8none|some|all|ignore|ignoreAll%E2%9F%A9]

[andreabedini]

If you check the status of -threaded on GHC, it seems as though the project is extremely stalled due to difficulty certain people are having with tests.

I understand what you say. I just believe cabal is not the place to fix GHC issues or tests. If some people have problems with GHC tests what makes you think cabal users won't have similar issues?

[liamzee]

I think we can make the change relatively simply on the Cabal end; i.e, put up a "-threaded" option during init.

But I'm aware that this could result in a deluge of issues; there are some libraries that behave differently depending on whether or not -threaded is on.

[gbaz]

if i'm not mistaken, this issue is not about invoking ghc with multithreaded compilation, but just about adding the flags to link executables against the threaded runtime by default?

which makes a lot of this discussion confusing to me.

That said, I think cabal should defer to whatever runtime ghc links against by default -- anything else would just introduce more places for confusion. Its reasonable to want ghc to link against the threaded runtime by default -- arguably we should have started doing that at the beginning of the 9.0 series at the latest (and even midway through the 8s). But that decision should be made by the ghc team and broader haskell community.

[liamzee]

As far as I understand, the -threaded change is approved on the GHC side, except that no proper implementation has been done.

The general point about moving issues to Cabal instead of GHC, however, basically comes down to whether Cabal maintainers would want to be responsible for issues with -threaded; i.e, some program behavior changes depending on whether the threaded runtime is used.

@gbaz

On GHC end:

https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0240-threaded-by-default.rst
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/538

I think I mentioned to maerwald about how ghc, cabal, and ghcup are basically Haskell's core tooling, and it's so tempting for each part of the core tooling to push responsibility to somewhere else.

Either setting a "threaded" option on cabal init or defaulting to it might be good until someone actually implements the ghc-proposal above.

[andreabedini]

The general point about moving issues to Cabal instead of GHC, however, basically comes down to whether Cabal maintainers would want to be responsible for issues with -threaded

That is a clear question with a clear answer :-) I would not want to be responsbile for this. GHC defaults are GHC's responsibility. Especially given GHC has already decided they are going to switch.