Newest at the top
2025-01-27 13:00:14 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 260 seconds) |
2025-01-27 12:59:57 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-01-27 12:57:46 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
2025-01-27 12:55:23 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
2025-01-27 12:53:37 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
2025-01-27 12:52:23 +0100 | <dminuoso> | well, you still have to fix the first list. ;) |
2025-01-27 12:49:49 +0100 | <lisbeths`> | lets say you compose a list of all of these technological problems you have mentioned about nix. and lets say you composed another list of all the reasons why you cant fix those problems on the first list. if you fix the problems on the second list then you will eliminate the issues youve mentioned with nix |
2025-01-27 12:49:10 +0100 | haritzondo | haritz |
2025-01-27 12:49:08 +0100 | <haskellbridge> | <magic_rb> you can also use libnix these days and spit out derivations |
2025-01-27 12:49:04 +0100 | haritzondo | (~hrtz@user/haritz) haritz |
2025-01-27 12:49:04 +0100 | haritzondo | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) (Changing host) |
2025-01-27 12:49:00 +0100 | <haskellbridge> | <magic_rb> you dont have to do it in nix tbh |
2025-01-27 12:47:56 +0100 | <dminuoso> | Given that the evaluator is built directly into nix, this turns into a "feel free to write a byte code compiler for nix" discussion. |
2025-01-27 12:45:53 +0100 | <haskellbridge> | <magic_rb> And the module system isnt slow, feel free to fix interpreter into a proper byte code one. Anyway sorry i gotta go do stuff |
2025-01-27 12:45:21 +0100 | <haskellbridge> | <magic_rb> Nix doesnt change often, the module system does |
2025-01-27 12:45:07 +0100 | <haskellbridge> | <magic_rb> I disagree |
2025-01-27 12:45:01 +0100 | <dminuoso> | But its not. |
2025-01-27 12:44:58 +0100 | <dminuoso> | I pointed out earlier: I think it would be better if it was not written and shoehorned into nix. |
2025-01-27 12:44:41 +0100 | <dminuoso> | Given that the module system is written in nix, I dont see how the distinction is meaningful. |
2025-01-27 12:44:39 +0100 | <haskellbridge> | <linj> any more |
2025-01-27 12:44:29 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Ping timeout: 260 seconds) |
2025-01-27 12:44:26 +0100 | <haskellbridge> | <magic_rb> Thats a nix problem, the evaluator is shit |
2025-01-27 12:44:18 +0100 | <haskellbridge> | <magic_rb> Thats not a module system problem |
2025-01-27 12:44:05 +0100 | <dminuoso> | Evaluation speed is horrible. |
2025-01-27 12:43:56 +0100 | hgolden_ | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
2025-01-27 12:43:41 +0100 | <haskellbridge> | <linj> what are your gripes with NixOS modules other than error messages? |
2025-01-27 12:43:31 +0100 | <haskellbridge> | <magic_rb> Which im personally against |
2025-01-27 12:43:28 +0100 | <haskellbridge> | <magic_rb> But also since i somewhat understand how the modulr system works i will say that not much can be improved without moving the implementation into Nix itself |
2025-01-27 12:43:26 +0100 | <dminuoso> | But the same could be said of just giving you a memory dump. |
2025-01-27 12:43:05 +0100 | <dminuoso> | Of course the stack tracers are helpful on the basis of "its better than nothing" |
2025-01-27 12:42:43 +0100 | <dminuoso> | ;) |
2025-01-27 12:42:40 +0100 | <haskellbridge> | <magic_rb> As i said not an excuse |
2025-01-27 12:42:26 +0100 | <dminuoso> | magic_rb: Imagine we had GHC internal stack traces on any compiler error instead of context, and you said "if you learn GHC enough, the stack traces do start making sense and are quite helpful" |
2025-01-27 12:42:24 +0100 | <lisbeths`> | cause my brain is smol |
2025-01-27 12:42:18 +0100 | <lisbeths`> | when I code in haskell (i (just (code (it (like (this)))))) |
2025-01-27 12:42:08 +0100 | <haskellbridge> | <magic_rb> Control flow is easy in nix imo, error handling, uh if then error dunno |
2025-01-27 12:41:46 +0100 | <dminuoso> | Not any different from Haskell, honestly. |
2025-01-27 12:41:42 +0100 | <haskellbridge> | <magic_rb> As for the module system, i feel you there. Its a mess, and while its not an excuse, if you use it enough the stack traves do start making sense and are quite helpful |
2025-01-27 12:41:38 +0100 | <dminuoso> | In scheme it is simple do write control flow and error handling, yes. |
2025-01-27 12:41:01 +0100 | <haskellbridge> | <magic_rb> Is scheme more suited? I think it really depends on your preferences, i find lisps quite hard to work with. Even good ones |
2025-01-27 12:40:33 +0100 | <dminuoso> | magic_rb: The module evaluator has very poor diagnostics. It's about the equivalent of a high school java project that just prints out Thread.currentThread().getStackTrace() |
2025-01-27 12:40:08 +0100 | Googulator | (~Googulato@2a01-036d-0106-1666-458a-5c2c-c01a-04f9.pool6.digikabel.hu) |
2025-01-27 12:39:53 +0100 | Googulator | (~Googulato@2a01-036d-0106-1666-458a-5c2c-c01a-04f9.pool6.digikabel.hu) (Quit: Client closed) |
2025-01-27 12:39:41 +0100 | <lisbeths`> | the scheme langauge is better suited for rapid development but the compiler is not as good which is a technical debt |
2025-01-27 12:38:38 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-01-27 12:37:23 +0100 | <haskellbridge> | <magic_rb> And yes the Guix folk do have a few things working way better than we do. One of them is bootstrapping |
2025-01-27 12:36:55 +0100 | <haskellbridge> | <magic_rb> Hardcore NixOS user here, what are your gripes with Nix/NixOS? |
2025-01-27 12:36:29 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
2025-01-27 12:36:07 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
2025-01-27 12:35:40 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |