nix: because primitive operations deserve to be spread equally between the prelude, builtins, lib, and "yeah we know this is widely useful but..."
A new chapter for the Nix language, courtesy of WebAssembly

Determinate Nix now supports Wasm functions in Nix expressions, bringing a range of new possibilities to the Nix ecosystem

@dramforever @whitequark

Uh...

> Finally, you could use import-from-derivation to declaratively build the Wasm module from source. But then you’re back to using import-from-derivation, which somewhat defeats the purpose!

How different is that from "You could use nix to compile your package, but that's slow. It's way faster to just fetch a prebuilt binary."~~~
@robryk @dramforever i think the problem with ifd is that it puts "nix-build" into the fixpoint loop, which is just really annoying. using wasm doesn't cause this because it's totally self-contained
@whitequark @dramforever

Using wasm the way they suggest (as opposed to using IFD to compile stuff to wasm) means that your nix code fetches a binary from somewhere and has no reason to trust that it corresponds to any known source. I'm trying to point out that this is exactly opposite to the direction nixpkgs is (was?) trying to go in most other situations (e.g. by fetching sources and not wheels from pypi, even when wheels would work).

@robryk @whitequark the thing they suggest is not that different from fetching .nix source code from the internet. i think it is preferable to IFD in the case of .nix code, and it's not any more worse than fetching .nix than importing wasm already was worse than importing .nix

i don't know why they didn't bother adding a hash to pin it - seems a weird practice to be showing off.

both IFD and fetching at eval time are forbidden by nixpkgs anyway.