2/2/2026 at 11:21:40 AM
Is this related to the Contracts RFC[1] and associated implementation[2] or is it its own freestanding work unrelated to upstream efforts?by OneDeuxTriSeiGo
2/1/2026 at 8:15:21 AM
by todsacerdoti
2/2/2026 at 11:21:40 AM
Is this related to the Contracts RFC[1] and associated implementation[2] or is it its own freestanding work unrelated to upstream efforts?by OneDeuxTriSeiGo
2/2/2026 at 8:31:32 AM
I was a bit skeptical at first coz my experience so far has been that Nix's weak typing quite rarely causes me problems.(Likely because NixOS options tend to be how I communicate between pieces of code, and those have a good enough type system).
But actually I think, as something that you just use occasionally like in your JSON example, this could be really cool. I wouldn't wanna use it as "gradual typing" in the sense of aiming to gradually type a whole body of code I think I would be more interested in "selective typing".
Just occasionally when you get that itch of "ugh this will fail really ungracefully if the inputs are bad" then you just apply this where it's needed.
by bjackman
2/2/2026 at 8:12:29 AM
Fun obscene fact! This site’s domain is sraka.xyz. In russian “sraka” is transliterated as “срака” which literally means ass.by sermah
2/2/2026 at 8:58:04 AM
in Polish its a vulgar term for "diarrhea"by sznio
2/2/2026 at 6:18:45 AM
Looks amazing!Some time ago I wanted to write a Nix configuration dsl for an application I use. My effort halted due to lack of type checking, and implementing one felt like too much effort which would never pay back.
I'll give a try.
by koiueo
2/2/2026 at 5:17:39 AM
Meh. Runtime assertions are a poor substitute for a type system, even if you give them a type-system-like syntax.by lmm
2/2/2026 at 5:36:28 AM
I think it's more nuanced than that.For a long-running program, like a network service or whatever, yes absolutely runtime assertions are a poor substitute.
For an impure program, where which branches of code are hit or aren't hit depends on the result of network calls, filesystem state, user input, etc, then yes, a type-system will be more powerful.
However, nix is more-or-less pure. By fully evaluating the output, you can hit all of the non-dead code, and hit every runtime assertion every time.
For a completely pure program, runtime and compiletime might as well be the same, running it and caching the output is the exact same as compiling it, and if it fails to run and outputs an error, that's the same as it failing to compile.
I know the "more-or-less pure" is doing a lot of work there, and in reality there's a lot of bits that aren't really pure, but it's close enough that a runtime type system gives you a lot more than you'd get from one in a traditional language.
by TheDong
2/2/2026 at 9:23:01 AM
This is a really good take.I think the core caution is this is not type-level checks. Anything this validates still needs to be eval'd. It's not a guarantee of correctness for all inputs but does look to be a fairly light (and useful) tool to make unexpected states easier for you and others to identify.
by _kb
2/2/2026 at 6:17:50 AM
Nix already has a ton written in it and it works... Magically.Gradual typing for a system like this is the proper thing to do. You can always write a static linter for sections you need tested and maybe eventually you'll be able to type nixpkgs as well.
Any solution to the nix typing problem NEEDS graduality. Nixpkgs is too large to make it possible to have one commit that fixes everything. Starting from scratch is not a realistic option either.
by anon291
2/2/2026 at 7:20:30 AM
Maybe you need graduality, sure. Plenty of systems (e.g. Typescript) have added a real type system that works gradually onto an existing system. While there are compromises to that approach, it's still a lot more effective than contracts IME.by lmm
2/2/2026 at 8:50:32 AM
How are well specified contracts different from type script? Typescript is just annotation. Behavior cannot change. This is annotation plus runtime examinable behavior. This approach seems conducive to static checkers.by anon291
2/2/2026 at 9:04:11 AM
> How are well specified contracts different from type script?Typescript has types, meaning expressions can be typechecked and this is distinct from evaluating them. Typechecking is more complete/consistent/reliable - you can catch type errors that don't show up in a codepath that gets actually executed. E.g. an empty list can be well typed, which as far as I can see you can't do with contracts.
by lmm
2/3/2026 at 5:24:20 AM
Typescript does not have a complete, consistent, or reliable type system, no. You can easily skirt around it. Indeed, there is no runtime guarantee at all. There is not even a function to enforce boundary conditions as far as I'm aware of. Contracts are better in every single way. Contracts are also type-checkable. Nix is deterministic and pure. You seem to be getting confused because contracts don't introduce new syntax.by anon291
2/3/2026 at 7:27:14 AM
> Typescript does not have a complete, consistent, or reliable type system, no. You can easily skirt around it.Most practical type systems are not technically complete, consistent, or reliable, and all have "escape hatches". That doesn't make them useless.
> Indeed, there is no runtime guarantee at all. There is not even a function to enforce boundary conditions as far as I'm aware of. Contracts are better in every single way.
On the contrary. That typescript types do not exist at runtime makes them much better than contracts in many ways.
> Contracts are also type-checkable.
Not in general. More to the point, not in a way that's general enough to rely on in practice.
> Nix is deterministic and pure.
And notoriously a nightmare to write and debug. Evidently "deterministic and pure" is insufficient. (I'd also argue that it's not actually pure in the ways that matter - see "The C language is purely functional")
by lmm
2/2/2026 at 4:56:33 AM
Sorry to be that guy. I love nix, I want to read more about how people use nix.The font presented under NixOS + Firefox is near unreadable on this website.
by bojo
2/2/2026 at 5:55:49 AM
The font (family) is a variant of Computer Modern. Computer Modern is, unfortunately, an extreme example of the problem where a font designed to compensate for ink spread on physical paper looks overly thin on a computer screen. It is also, unfortunately, one of the very few free fonts with good support for mathematics.by mananaysiempre
2/2/2026 at 8:48:02 AM
Have you tried enabling Reader Mode in your browser?by yakshaving_jgt
2/2/2026 at 10:49:15 AM
Does not work nice with code blocks. But here's how you can add Javascript Snippets to every webpage via Tampermonkey: // ==UserScript==
// @name JS Snippets
// @match *://*/*
// @grant GM_registerMenuCommand
// ==/UserScript==
GM_registerMenuCommand("Set font to default", () => {
document.querySelectorAll("body *:not(pre *)").forEach(el => {
el.style.fontFamily = "nonExistentFont";
});
});
you can run them by clicking the Tampermonkey icon and picking the action you want. You can add website dependent snippets by checking the location before you register the menu items, it's dynamic.
by bmacho
2/2/2026 at 6:05:11 AM
[flagged]by boycothn