Next talk starts at 15 UTC, that is in 2 hours. I'll be speaking how about how to get Nix to become mainstream.
Oh, that's good to know because cfp.nixcon.org says 15:00 but without timezone, so I assumed it was 15:00 in my timezone!
NixCon Live
11–20 of 50 posts
Re: NixCon Live
#12Earlier quoted context omitted.
Is this harder to achieve for the Rust ecosystem (due to some properties of Haskell perhaps)? Or just no one put in the effort in doing it? Is it expensive to maintain all the binaries for all of Hackage?
It's not inherent to the language. It's inherent in the build tooling. Back in the cabal days haskell had the same problems. Nix is a more hermetic build and packaging tool which is why it's better at it.
Very curious to read about what it means to have a `hermetic build and packaging tool`.
In my naive view, there should be a way to at least cache the latest successful build from a package version. Then when users `cargo install ..`, it will check if a build was already made and retrieve it.
Re: NixCon Live
#13Next talk starts at 15 UTC, that is in 2 hours. I'll be speaking how about how to get Nix to become mainstream.
Oh, that's good to know because cfp.nixcon.org says 15:00 but without timezone, so I assumed it was 15:00 in my timezone! https://cfp.nixcon.org/nixcon2020/schedule/
Yes, blame me for this one. I didn't have things ready quickly enough to fix certain important user experience aspects like "showing the timezone".... which is kind of a basic and critical need.
Anyways, the widget at https://2020.nixcon.org/#program localizes to your timezone (but also shows weird dates sometimes).
Times from the cfp subdomain are all in UTC.
Re: NixCon Live
#14Earlier quoted context omitted.
It's not inherent to the language. It's inherent in the build tooling. Back in the cabal days haskell had the same problems. Nix is a more hermetic build and packaging tool which is why it's better at it.
Very curious to read about what it means to have a `hermetic build and packaging tool`. In my naive view, there should be a way to at least cache the latest successful build from a package version. Then when users `cargo install ..`, it will check if a build was already made and retrieve it.
Nix is a tool for deployment, that happens to have some build capabilities. This is how I view it anyway.
Re: NixCon Live
#15I've been using Nix OS since this year and am mostly happy with it, but if I had to name my largest issue with it then it's that updates are so traffic intensive. Basically, glibc is linked dynamically on most distros, including Nix OS. But if there is a glibc update that only changes the .so file, it still updates all packages depending on glibc.
A more expansive list of my issues with nix (with some curse words :p): https://gist.github.com/est31/005f17628d55fda27b401d3c994233...
Re: NixCon Live
#16I've been using Nix OS since this year and am mostly happy with it, but if I had to name my largest issue with it then it's that updates are so traffic intensive. Basically, glibc is linked dynamically on most distros, including Nix OS. But if there is a glibc update that only changes the .so file, it still updates all packages depending on glibc. A more expansive list of my issues with nix (with some curse words :p)…
I'm confused with your first point?
> No concept of source packages. There is only a binary cache (hydra) and the derivations in nixpkgs.
NixOS _Only_ has a concept of source packages. The cache is a (sound) optimisation om top of it. just disable the binary cache and you can build all packages from source.
Re: NixCon Live
#17Earlier quoted context omitted.
It's not inherent to the language. It's inherent in the build tooling. Back in the cabal days haskell had the same problems. Nix is a more hermetic build and packaging tool which is why it's better at it.
Very curious to read about what it means to have a `hermetic build and packaging tool`. In my naive view, there should be a way to at least cache the latest successful build from a package version. Then when users `cargo install ..`, it will check if a build was already made and retrieve it.
"at least cache the latest successful build from a package version"
Tools like guix and nix aim to describe packages in such a way that for the same input (package dependencies) you get the same output.
If the output is a function of the input, and you know a cached build of a package was built with the same input, then using the cached build of a package would be the same as if you'd built it yourself.
It does depend on whether the packages are written in a "pure" way. (Or "impure", such that building with the same inputs might result in different outputs). https://github.com/NixOS/nix/issues/2270
Re: NixCon Live
#18Earlier quoted context omitted.
It's not inherent to the language. It's inherent in the build tooling. Back in the cabal days haskell had the same problems. Nix is a more hermetic build and packaging tool which is why it's better at it.
Very curious to read about what it means to have a `hermetic build and packaging tool`. In my naive view, there should be a way to at least cache the latest successful build from a package version. Then when users `cargo install ..`, it will check if a build was already made and retrieve it.
[deleted]
Re: NixCon Live
#19Earlier quoted context omitted.
The situation for installing haskell programs with nix is great, practically everything from hackage is available in the binary cache.
Is this harder to achieve for the Rust ecosystem (due to some properties of Haskell perhaps)? Or just no one put in the effort in doing it? Is it expensive to maintain all the binaries for all of Hackage?
There's a couple of challenges here with Rust. None are insurmountable, but there are just other things that are higher priority.
There are 15,000 packages on Hackage, but 48,000 on crates.io. According to http://www.modulecounts.com/ hackage is getting about four new packages a day right now, and crates.io is getting 54. This means that expense is more of an issue.
I don't know about Haskell, but in Rust, many projects tweak various compiler flags, for performance, or whatever. You'd need to get the exact flags the same too. It's possible there's a long tail effect here.
https://doc.rust-lang.org/nightly/rustc/platform-support.htm... is way longer than https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms (I am not 100% sure the latter is canonical). This isn't a hard stopper, and there's probably a long tail effect here, but it's still a factor in you getting a precompiled binary or not.
Rust relies more heavily on inlining than Haskell does, and relies heavily on monomorphization This means more work to do during compilation; it also means that even for a "precompiled binary", you still end up needing to do a lot of work on the final compilation.
There are existing tools like sccache that you can use to implement a binary cache, so people that really want this feature also have the ability to get it, and some do. It's just not a globally available thing.
If you look at Rust's compile times, generally, even once your dependencies are compiled, it's still slower than we'd like. You only compile dependencies once, and so, while binary libraries may help your initial build, they don't really affect later builds at all, and that's most builds. So more effort is going into improving that, rather than focusing on pre-compiled dependencies.
That's off the top of my head...
Re: NixCon Live
#20I've been using Nix OS since this year and am mostly happy with it, but if I had to name my largest issue with it then it's that updates are so traffic intensive. Basically, glibc is linked dynamically on most distros, including Nix OS. But if there is a glibc update that only changes the .so file, it still updates all packages depending on glibc. A more expansive list of my issues with nix (with some curse words :p)…
I'm confused with your first point? > No concept of source packages. There is only a binary cache (hydra) and the derivations in nixpkgs. NixOS _Only_ has a concept of source packages. The cache is a (sound) optimisation om top of it. just disable the binary cache and you can build all packages from source.
Nix packages don't contain any source code.
The package definition describes how to fetch the source code from a source (like a Git repo or a hosted archive) and build it. The built result only contains what is necessary at runtime.
A sizeable amount of packages don't even fetch source code but a prebuilt binary which is then fixed up to work with Nix.
There is a source cache, but it is optional.
As an example, check out ripgrep [1]. It uses `fetchFromGithub` to retrieve the code.
[1] https://github.com/NixOS/nixpkgs/blob/3bb54189b0c8132752fff3...