| 29 Jul 2022 |
 infinisil | * Bash in that sense is terrible because it's just a string, you can't inspect that at all. The phases add some level of static inspection on top of it, but it's not great or well specified | 18:20:37 |
| infinisil | isomorphic stdenv? | 18:20:46 |
 profpatsch | (isomorphic in the sense of isomorphic javascript) | 18:20:47 |
| infinisil | (that doesn't help!) | 18:21:02 |
| profpatsch | javascript that you write once and can transparently run on the server or client, with the same semantics | 18:21:10 |
| infinisil | Ahh | 18:21:20 |
| profpatsch | so i.e. you would have a DSL and on the client it modifies the DOM, on the server it pre-renders the UI and sends the HTML | 18:21:38 |
| profpatsch | This but for a nix stdenv dsl which could either be interpreted at build time or at evaluation time. idk if I’m making sense :P | 18:22:24 |
| profpatsch | inb4 nixpkgs compilation phase | 18:22:48 |
| infinisil | I kind of get it, though actually getting what it means in practice is tricky | 18:22:56 |
| profpatsch | But this is very far-removed from practice yeah | 18:23:04 |
| profpatsch | not even sure one would even want something like htis | 18:23:23 |
| infinisil | I guess it goes into using Nix as a make replacement | 18:23:32 |
| infinisil | cc Maak | 18:23:40 |
| profpatsch | something like that | 18:23:40 |
| profpatsch | Or like Ur/web, where you write one (typed) function in one language, but parts of it get executed in the database, parts on the server, and parts in the UI | 18:24:43 |
| profpatsch | And it’s more-or-less transparent to the user | 18:24:55 |
| profpatsch | like what if you could define declarative derivations down to the file-action, but then it would compile parts of the definition to a builder | 18:25:52 |
| infinisil | Yeah | 18:26:13 |
| profpatsch | building execline argv lists is already something like that | 18:26:27 |
| infinisil | Ultimately it's specifying what happens at runtime with Nix 🤔 | 18:27:16 |
| profpatsch | yeah, maybe even without noticing the border if you don’t want to | 18:27:45 |
| profpatsch | maybe the border moves around flexibly in the background :P | 18:28:28 |
 yorik.sar | We could so defer generation of builders from Nix by serializing not yet applied functions and creating derivations for builders. | 20:32:15 |
| yorik.sar | * (null) | 20:32:27 |
| 30 Jul 2022 |
 DavHau | In reply to @kevincox:matrix.org
This strikes me as likely to add far more complexity than value. In what way would that add complexity? I think having clean interfaces between phases is a necessary step towards sanity. That would allow us to have real modularity of builds, where we can have reasonable assumptions about what will happen during a build, vs right now, for most users everything is a huge black box which is hard to debug. I'm also not worried about runtime performance. With the current bash based model, CPU cycles are wasted initializing an unnecessary amount of processes for simple operations like symlinking etc. If proper interfaces allowed us to implement build phases in the language that suits best for that phase, we will gain a lot of efficiency. Even if we have to run an extra process per phase the performance might be orders of magnitude better. | 09:41:58 |
 Alyssa Ross | Processes are not created equal | 09:43:15 |
| Alyssa Ross | (not disagreeing, just want to point out) | 09:43:26 |
| Alyssa Ross | fork+exec overhead is trivial compared to e.g. interpreter startup time for most languages | 09:43:38 |
| Alyssa Ross | so (just as an example) I'd expect you could run many lns before Python has started up | 09:44:16 |
