Tix is a bespoke type checker/LSP for nix. It is based on algebraic sub typing and support narrowing through negation types. I’ve been working on it for a while and now happy enough with it to share it out some more.
Some cool features
Jump to def into nixpkgs
Doc/autocomplete for nixos options
Autocomplete all nixpkgs pkgs
Note: while I did start this project a year ago myself, when i picked it back up a few months ago I’ve been primarily developing it with claude. If you feel strongly about vibe coded projects, I get it but hope you still try it out!
f you feel strongly about vibe coded projects, I get it but hope you still try it out!
Yes I do feel strongly about slopcoding, no I can’t try it out since I feel strongly about it.
EDIT: i wasnt initially sure why this bothered me so much, but now i know. Its extremely dimissive, on the one hand you say you know all the problems with utilizing LLMs, yet you ask me to ignore them to checkout your project. Next time just plainly state at the top of your annoucement “created using an LLM” and all will be swell.
Seriously very cool, surprised that your post has received so little traffic.
Do you have a short overview about what you think makes it special? How would you say it compares to nixd/nil in capabilities?
Also do I understand correctly that some code actions are already supported?
This seems particularly neat. I however cannot see myself personally adopting this or taking it seriously in a standard perspective.
Firstly I think just slapping stubs on the code is a half-measure, and not actually basing your source of truth in the code itself. I think it probably would’ve made a bit more sense to use comments like jsdoc, like we already do in nixpkgs.
Second, the fact this was vibecoded puts the project under a lot more scrutiny regarding its stability, security, and design. (AI tends to roll with poor ideas, while engineers sleep on things and iterate on their ideas)
All in all I suppose it is neat this exists, and I personally hope someone find this useful and incorporates it into their workflow; In the end I hope it solves real problems.
This does make me wonder about instead annotating all the builtins and then performing static analysis on functions boiling them down to their builtins and then computing the resulting signature.
I hope you can find it in yourself to maybe iterate or redo the project on your own. I promise you you can do it, and I promise you the impl will be cleaner and more sound in design if you apply yourself.
Many of the builtins already have type signatures(in nix’s custom doc comment format, but type signatures nonetheless exist)
For instance, see builtins.add on noogle. There’s still a lot of work to be done typing a large amount of nixpkgs’ lib, but having the unified doc comments has done a lot of good for nix typing. Hoping that tooling like this and nixd/nixf(which are what I personally use) can leverage this sort of typing for a better nix development experience.
Yeah I think for an actual full measure putting energy towards doc comments is the way to go. Speaking of which, it’s been a while since I have looked into doc comments and I have forgotten like everything about them (Very telling how little I document my Nix code isn’t it?), do they support specifying the arg type? And It just now realize how stupid I sound. Of course they do, you just said so…
However, a less stupid question; Do the two main LSP impls utilize doc comments?
The idea of this project looks truly amazing . To some extent, it has accomplished something I wanted to do in nixd but never got around to implementing. Perhaps my knowledge of programming languages is indeed relatively weak, but judging from the blog, this feels like a meaningful direction to pursue. As for the LSP side, it seems like a particularly engineering-heavy, somewhat “labor-intensive” endeavor, and I personally may not have the time to complete it. If possible, I’d like to kindly suggest you to explore whether if the type system can be integrated into existing LSPs — the current state of LSPs in the NixOS community is still too fragmented.
Your point on LSP being engineering heavy is very true. Honestly the type checking part while “hard” is much easier to feel better about. Its much simpler to verify where as LSP has much more “real engineering” needed behind it and at least for me required a lot more thought to get something workable
I’d be happy to work on making the type checking part of this much easier to expose as a library so other LSPs can hook in more easily
This does make me wonder about instead annotating all the builtins and then performing static analysis on functions boiling them down to their builtins and then computing the resulting signature.
This does work now but only within the scope of a single file. Tix does support the same doc comment annotations used in nixpkgs lib.
I made the design decision from the beginning to use stubs from my experience of using type script. I felt like it was a good simplifying assumption to even undertake this project.
After going through with it now, i am more inclined to do more project wide inference since the performance has been pretty good so far but I still think using something like stubs (maybe through really good caching) will be needed to have a good IDE experience
I like it, and I hope you are not put off by comments by people who ideologically do not judge code by what it is but by how it came to be.
I didn’t look yet closely enough to analyze this, but this does touch points I’ve felt are a bit sore in the nix community, such as the canonical implementation of the language being at the same time the specification and not even intended to be usable in tooling. Granted, typing is in many ways a different problem than arguing about precise weird historical semantic quirks (and typing is something which I’ve wanted every time I write nix!); but I think the problem starts from more mundane layers such as parsing.
. To some extent, it has accomplished something I wanted to do in nixd but never got around to implementing. Perhaps my knowledge of programming languages is indeed relatively weak, but judging from the blog, this feels like a meaningful direction to pursue. As for the LSP side, it seems like a particularly engineering-heavy, somewhat “labor-intensive” endeavor, and I personally may not have the time to complete it. If possible, I’d like to kindly suggest you to explore whether if the type system can be integrated into existing LSPs — the current state of LSPs in the NixOS community is still too fragmented.