Haskell in Nixpkgs/NixOS | 724 Members | |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | More Nix: #community:nixos.org | More Haskell: #haskell-space:matrix.org | 144 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 Feb 2025 | ||
| 21:48:24 | ||
| 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 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 | 21:54:57 | |
| do you plan to update to Nixpkgs 25.05? | 22:00:47 | |
| I would like to, ideally we could have a working build with the latest nixpkgs. | 22:04:58 | |
| dmjio: What exactly do you mean with "regressions in closure compilation"? | 22:05:09 | |
| dmjio: Which libraries are you using? | 22:05:52 | |
| 9.10 payload sizes I think? | 22:05:51 | |
| but that build doesn't need to be 8.10 ghcjs right? | 22:08:37 | |
| By the way throwing flakes, the new js backend, haskell.nix, nixops and jsaddle-warp together sounds a bit like FUD to me. I get the sentiment, but no one is forcing you to use haskell.nix or flakes and this is all orthogonal to deployment. If you say, that you are currently using ghcjs in nixpkgs and that there are specific things missing for you to switch to the new backend, that is a very valuable data point. | 22:10:38 | |
| maralorn: three things particular
| 22:12:00 | |
| * maralorn:
| 22:12:13 | |
| * maralorn:
| 22:12:38 | |
| https://github.com/ghcjs/ghcjs/issues/821#issuecomment-1129388366 | 22:13:14 | |
| 22:15:31 | |
| kk. I know 1, I don’t know how problematic that is. 2. is not completely solved but the new backend is better than ghcjs 8.10 afaict. 3. I thought that closure compiler works with the new backend (see: https://blog.haskell.org/case-study-foreign-integration-js-browser/). | 22:15:33 | |
| so that's ~10MB pre closure compiler and pre-compression | 22:16:15 | |
| which doesn't sound too big given I've reached 100MB on 8.10 at that stage hhe | 22:16:41 | |
| * which doesn't sound too big given I've reached 100MB on 8.10 at that stage heh | 22:16:45 | |
| But if 2. is really a problem for you, does that mean you are still on ghcjs 8.6? If yes, then you are currently not on a working nixpkgs and us dropping 8.10 wouldn’t make a difference, would it? | 22:16:56 | |
| * But if 2. is really a problem for you, does that mean you are still on ghcjs 8.6? If yes, then you are currently not on an up-to-date nixpkgs and us dropping 8.10 wouldn’t make a difference, would it? | 22:17:26 | |
| Well yes and no, if you don't keep in lockstep with the community eventually everything bitrots to the point where it can't be built. That's why nix has been great so far, but the critical mass of the community is converging around tooling that introduces imo significant regression | 22:17:57 | |
| I would understand that. We are on 8.6 at work exactly for this reason. That is why we don’t care about dropping 8.10 its useless to use anyway. | 22:18:06 | |
I'm personally not, but other people I know who use miso at work do use 8.10 | 22:18:29 | |
| Ok then we're in the same boat | 22:18:48 | |
| Isn't miso's nixpkgs pin ~2 years old? The same goes for reflex-platform which is why we had been assuming everyone would jump from old nixpkgs with 8.x ghcjs to new nixpkgs with 9.12+ | 22:19:21 | |
| the question is whether anyone needs a new nixpkgs with a 8.x ghcjs | 22:19:38 | |
| Anyway we can’t do anything about flakes. And we in this channel generally don’t want to switch to haskell.nix. The bitrotting of ghcjs is sad, but that’s why it is awesome that there is the new backend. | 22:20:04 | |
| * I would understand that. We are on 8.6 at work exactly for this reason. That is why we don’t care about dropping 8.10 its useless to us anyway. | 22:20:13 | |
| 6 years old | 22:21:07 | |
In reply to @dmjio:matrix.orgThat's a little scary | 22:21:20 | |