| 26 May 2021 |
 Jonas Chevalier | ahem :) | 10:35:35 |
 Gytis Ivaskevicius | Do you guys think that it would be worth replacing bash within few years timeline? 🤔 | 10:36:03 |
 andi- | If it provides benefits over just not being bash :D | 10:36:21 |
| Gytis Ivaskevicius | (And honestly i'd love to see some linux disto that is like "fuck posix, and other old standards") | 10:36:51 |
| andi- | If I can write more nix code instead of bash for complex builds. stdenv.doBuild { steps = [ (mkDir "foo") (chDir "foo") (invoke "make") ]; } | 10:37:01 |
| Jonas Chevalier | at the moment we don't have much visibility on how much bash is an overhead to build times | 10:37:02 |
| Gytis Ivaskevicius | In reply to @andi:kack.it
If it provides benefits over just not being bash :D How much value are we talking about? | 10:37:07 |
| Jonas Chevalier | I bet there is a factor of 10 available for small derivations | 10:37:17 |
| Gytis Ivaskevicius | In reply to @zimbatm:numtide.com
I bet there is a factor of 10 available for small derivations oh yeah, in fact maybe small binary or nix builtin should be written for trivial-builders.nix | 10:37:54 |
| andi- | Oh yes | 10:37:56 |
| andi- | When I was working on my package set it became so obvious how slow bash is :/ | 10:38:15 |
| andi- | Simply not having any stdenv was so much fast :D | 10:38:31 |
| andi- | In reply to @gytis-ivaskevicius:matrix.org
How much value are we talking about? I think a guix style benefit would be nice but probably not realistic as they also execute guile within the build. | 10:39:16 |
| Jonas Chevalier | that's another benefit of experimenting with scratchix | 10:39:58 |
| Jonas Chevalier | it allows to play with ideas like that | 10:40:06 |
| Gytis Ivaskevicius | In reply to @andi:kack.it
I think a guix style benefit would be nice but probably not realistic as they also execute guile within the build. if i recall correctly they use the lispy shell which is basically unusable shell and more like proper lispy programming language | 10:40:33 |
| andi- | Yeah, that is fine for build scripts | 10:41:03 |
 toonn | Being able to reuse Guix work would be pretty cool though. | 10:41:14 |
| andi- | Probably not practical as they have a nice integration from eval -> derivation where they can pass lipsy code, no? | 10:42:04 |
| andi- | Instead we are stuck with our custom Nix interpreter that can't even be used outside of a store environment.. | 10:42:29 |
| Jonas Chevalier | When you write a nix template and then find out that some parameters need to be filled in at runtime | 10:43:12 |
| Jonas Chevalier | How many times I had to tack on some sed to fill the runtime info. Or some mix between bash at runtime and nix as eval time. | 10:44:14 |
| andi- | In a way the language that you use to describe the build environment must also drive it. | 10:45:28 |
| andi- | Or you always end up with the split we are having right now. | 10:45:38 |
| Jonas Chevalier | It reminds me of terraform that has two languages into one | 10:46:45 |
| toonn | Though you kinda always have to bridge to shell eventually. Because that's what most build tools expect. | 10:46:57 |
| andi- | Yes but usually you call a bash script and only care about the result. You never (or rarely?) consume the environment it created. You can just call another shell script from your clean shell env. Problem arises when you have to use the output of a previous phase. | 10:49:03 |
| andi- | Gytis Ivaskevicius: btw: the gccgo9 build did finish with this line:
cycle detected in the references of '/nix/store/37msxfm5cil2m4cvn06yb7miv68j9pk5-gccgo9-9.3.0-lib' from '/nix/store/xdyzifmvys1gna6fcbmvc6wahd5cy0vn-gccgo9-9.3.0'
| 10:50:15 |
| andi- | but otherwise looked good :D | 10:50:21 |
| Gytis Ivaskevicius | :D | 10:51:12 |
