In reply to @emilazy:matrix.org
GHC is in the critical path for building a working Nixpkgs. the bootstrap pulls in an unsupported LLVM that doesn't build with modern compilers without patching and keeps requiring manual work to backport fixes. it has broken during recent staging cycles and it has fallen on Darwin maintainers to fix it because we cannot just ignore it. if there are substantive technical blockers to fixing this, then I want to work to address them. if there is a meaningful external userbase that relies on using those unsupported compilers with a supported Nixpkgs then I want to hear from them and discuss what the long-term options are. but it is a major burnout factor to have to repeatedly take responsibility for maintaining a codebase that we would rather be outside our purview because it very indirectly blocks the world and one maintainer can't decide what the reason it has to stay is

In reply to @maralorn:maralorn.de
sterni: I am here. I actually use ghcjs every day. I can tell you that we can drop it.

alexfmpe sterni I'm open to moving to the new JS backend, but last I checked there were some outstanding regressions in closure compilation that significantly affect payload size (maybe I'm out of date now?), and some new runtime errors that users were reporting (despite the fact that it builds). The original GHCJS (that miso caches) has a working GHCJSi, TH support, payloads amenable closure compilation, and the fewest runtime errors.

It seems the community has moved on to using an experimental build tool (flakes), a new compiler (which has introduced seemingly significant regressions for JS code output) and a new haskell package infra (haskell.nix), and has chosen to replace GHCJSi w/ the package jsaddle-warp and nixops is on life support.

Was considering the WASM backend as default instead because they support GHCi and TH now, but getting a proper nix derivation for it (it forks llvm to add a custom allocator -- maybe we should consider zig cc ?) to work with crossPkgs seems like a non-starter (according nix experts) and from my own experiments manually applying the ghc wasm patches to llvm in nixpkgs.

So the situation is less than ideal imo. In summary if the regressions can be addressed for the js closure compilation that would make me feel a little more comfortable, but I'd like to keep ghcjs around until feature parity is reached w/ the new JS backend.

maralorn: three things particular

1. Linking (JS file concatenation) can cause OOMs (still) in CI servers - I think this has always been a problem though.
2. The optimizer that typically runs was disabled (I'm not sure if they fixed that upstream, but modifications to it caused them to rethink)
3. Closure compiler support stopped working and payload size got much larger
4. Newer versions of nix don't work with miso's default version of nixpkgs ld: file not found: /usr/lib/system/libcache.dylib for architecture x86_64

maralorn: three 4 things particular

1. Linking (JS file concatenation) can cause OOMs (still) in CI servers - I think this has always been a problem though.
2. The optimizer that typically runs was disabled (I'm not sure if they fixed that upstream, but modifications to it caused them to rethink)
3. Closure compiler support stopped working and payload size got much larger
4. Newer versions of nix don't work with miso's default version of nixpkgs ld: file not found: /usr/lib/system/libcache.dylib for architecture x86_64

maralorn: three 4 things particular

1. Linking (JS file concatenation) can cause OOMs (still) in CI servers - I think this has always been a problem though.
2. The optimizer that typically runs was disabled (I'm not sure if they fixed that upstream, but modifications to it caused them to rethink)
3. Closure compiler support stopped working and payload size got much larger
4. Newer versions of nix don't work with miso's default version of nixpkgs on Darwin. ld: file not found: /usr/lib/system/libcache.dylib for architecture x86_64

1. This is the thing that got disabled in 8.10 I believe. I seem to recall in #ghc-js-backend:matrix.org them telling me that thing in particular was still disabled, but a ton of other optimizations had been done that probably maked up for it
   One of the reasons I was getting miso-examples building in nixpkgs was to peek at the resulting sizes but I'm a bit confused on whether I have the right output due to some "undefined" errors when running.
   FWIW, here's what I got so far on my branch (no closure compiler AFAICT)

> l $(NIXPKGS_ALLOW_BROKEN=1 nix-build -A pkgsCross.ghcjs.haskell.packages.ghc912.miso-examples)/bin
total 110M
dr-xr-xr-x 1 root root  160 jan  1  1970 .
dr-xr-xr-x 1 root root   16 jan  1  1970 ..
-r-xr-xr-x 2 root root 9.3M jan  1  1970 canvas2d
-r-xr-xr-x 2 root root 9.6M jan  1  1970 compose-update
-r-xr-xr-x 2 root root 9.7M jan  1  1970 file-reader
-r-xr-xr-x 2 root root 9.7M jan  1  1970 mario
-r-xr-xr-x 2 root root 9.2M jan  1  1970 mathml
-r-xr-xr-x 2 root root  12M jan  1  1970 router
-r-xr-xr-x 2 root root  11M jan  1  1970 svg
-r-xr-xr-x 2 root root 9.4M jan  1  1970 threejs
-r-xr-xr-x 2 root root  11M jan  1  1970 todo-mvc
-r-xr-xr-x 2 root root  11M jan  1  1970 websocket
-r-xr-xr-x 2 root root  11M jan  1  1970 xhr