Newest at the top
| 2024-10-28 19:33:22 +0100 | kuribas | (~user@ptr-17d51epnnpcnu3v8qjj.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2024-10-28 19:23:15 +0100 | euleritian | (~euleritia@dynamic-176-006-145-033.176.6.pool.telefonica.de) |
| 2024-10-28 19:22:38 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds) |
| 2024-10-28 19:21:16 +0100 | <haskellbridge> | <Bowuigi> Likely, yeah, smalltt is interpreted (very quickly, haven't yet seen benchmarks against Lua/LuaJIT tho) so it can't get low level and super optimized |
| 2024-10-28 19:19:19 +0100 | <dolio> | I think you can write things that are very fast, though. |
| 2024-10-28 19:18:58 +0100 | <dolio> | And questionable amounts of actual dependent typing. |
| 2024-10-28 19:18:48 +0100 | <dolio> | ATS is a frankenstein's monster system with all kinds of low-levelish stuff. |
| 2024-10-28 19:17:55 +0100 | <haskellbridge> | <Bowuigi> Building can't get much faster than it is now, maybe changing the shell helps but likely not much. As usual, other measures to make compilation quicker (ccache, using a faster linker, etc) could also help |
| 2024-10-28 19:16:41 +0100 | <haskellbridge> | <Bowuigi> The slowest parts of Nix are importing nixpkgs and actually building. We can fix the first one by, well, not using a huge record defined across a gazillion files. Separate the ecosystem into categories and import each separately, heavily reducing the IO operations and the execution time |
| 2024-10-28 19:16:13 +0100 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 245 seconds) |
| 2024-10-28 19:14:48 +0100 | Nachtgespenst | (~user@user/siracusa) (Quit: Bye!) |
| 2024-10-28 19:14:28 +0100 | <haskellbridge> | <Bowuigi> Indeed, row types are supposed to work well with records and variants, and since Nix uses both extensively (mkForce, mkDefault and friends are variants that change the behaviour of record merging) |
| 2024-10-28 19:12:56 +0100 | <sshine> | sorry, vice versa |
| 2024-10-28 19:12:41 +0100 | vglfr | (~vglfr@2607:fb90:a837:c1df:ad6:1a51:e325:8c1) vglfr |
| 2024-10-28 19:12:40 +0100 | <sshine> | it occurs to me that Nix is particularly well-suited for row types |
| 2024-10-28 19:12:03 +0100 | vglfr | (~vglfr@2607:fb91:1481:17a0:ac39:6af7:4dd8:d9b1) (Ping timeout: 252 seconds) |
| 2024-10-28 19:11:56 +0100 | <haskellbridge> | <Bowuigi> Nix requires something like the lang I'm designing (F omega, row types, generic row operations, etc) but a bit simpler and way faster |
| 2024-10-28 19:11:55 +0100 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2024-10-28 19:10:11 +0100 | <haskellbridge> | <Bowuigi> Gradual typing is a bad idea that happened to barely work a few times. Combine that with union types and you get a type system that is easy to render useless or distracting (like TypeScript) |
| 2024-10-28 19:09:20 +0100 | <haskellbridge> | <Bowuigi> Typechecking should be, evaluation depends on whether ATS is being compiled or interpreted and the size of the program |
| 2024-10-28 19:08:33 +0100 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-10-28 19:08:26 +0100 | <dolio> | Is it faster than ATS? |
| 2024-10-28 19:08:08 +0100 | <haskellbridge> | <Bowuigi> By the author of flatparse |
| 2024-10-28 19:07:54 +0100 | <haskellbridge> | <Bowuigi> https://github.com/AndrasKovacs/smalltt the fastest dependently typed lang around |
| 2024-10-28 19:07:42 +0100 | vglfr | (~vglfr@2607:fb91:1481:17a0:ac39:6af7:4dd8:d9b1) vglfr |
| 2024-10-28 19:07:04 +0100 | <sshine> | what's smalltt? |
| 2024-10-28 19:06:53 +0100 | vglfr | (~vglfr@c-73-250-25-113.hsd1.md.comcast.net) (Ping timeout: 255 seconds) |
| 2024-10-28 19:06:52 +0100 | <haskellbridge> | <Bowuigi> It could work with a row typed lang with smalltt level performance tho |
| 2024-10-28 19:06:45 +0100 | <sshine> | Bowuigi: I see that some people try to talk about schemas. surely one could imagine gradual/optional typing? |
| 2024-10-28 19:05:37 +0100 | <haskellbridge> | <Bowuigi> sshine The strongest argument against that is that nixpkgs is a stupidly large record (100k fields pretty much) |
| 2024-10-28 19:05:32 +0100 | <sshine> | (assuming I'm already on the 95th floor of Nix Towers) |
| 2024-10-28 19:05:32 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2024-10-28 19:05:01 +0100 | <sshine> | either way, I'm grateful that the package just works. changing the GHC packaage and re-testing, and it just fetches the newer GHC, recompiles dependencies, and passes test without a hitch. truly remarkable, and low effort, really. |
| 2024-10-28 19:03:42 +0100 | <sshine> | I wonder if the Nix language will ever get a type system, or if that's a lost cause. |
| 2024-10-28 19:03:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-10-28 19:02:54 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 276 seconds) |
| 2024-10-28 19:02:54 +0100 | <sshine> | ...because the author thought: I'll beat the second-best package because it was getting stale, and I'll do so by not only improving on the package's quality, but the documentation and the examples and the general availability. Nix isn't like that. |
| 2024-10-28 19:01:48 +0100 | <sshine> | I wish it were like finding a really good Haskell or Rust package. you go to the official documentation site, and the package's documentation is nicely formatted, easily searchable, and kind of works like a small tutorial not only to the package but to the problem space it fills. |
| 2024-10-28 19:01:44 +0100 | <c_wraith> | fwiw, I will do things like fromMaybe (error "you refactored valueThatWillNeverBeNothing and broke it") valueThatWillNeverBeNothing |
| 2024-10-28 19:01:08 +0100 | <sshine> | I've drunk the Nix koolaid, and I'm all in. but yeah, it's always pretty steep to learn how things work. |
| 2024-10-28 19:00:21 +0100 | <geekosaur> | eh, it's flexible, it's just not possible to understand how to access that |
| 2024-10-28 18:59:46 +0100 | <sshine> | just so we get the flexibility ordering straight: stack < nix < overcooked noodles |
| 2024-10-28 18:59:43 +0100 | <c_wraith> | noodles are pretty bad build systems, though |
| 2024-10-28 18:59:25 +0100 | <sshine> | nix is nowhere close to the flexibility of a bowl of overcooked noodles! |
| 2024-10-28 18:57:57 +0100 | <Franciman> | tho |
| 2024-10-28 18:57:55 +0100 | <Franciman> | sshine: stack is nowhere close to nix's flexibility |
| 2024-10-28 18:57:06 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-10-28 18:56:18 +0100 | euleritian | (~euleritia@dynamic-176-003-056-049.176.3.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2024-10-28 18:56:13 +0100 | <sshine> | I think the only convenience I get now is muscle memory. |
| 2024-10-28 18:55:49 +0100 | <sshine> | but I also realize that my need back then for using Stack has largely been superceded by Nix. |