I use the syntax of nix (and SML derived languages in general) as a reminder to myself that those who complain about the syntax of Lisp probably just have different taste than me, because there are people out there who prefer the syntax of nix to that of Lisp.

Yes. I couldn’t get comfortable with Guile for Guix, but having touch PureScript, Haskell, OCaml, Nix feels at home (other than the need for dymanic types).

They really wrote the whole post without explaining the puns ... that shows incredible self control, because I find them to be pretty good.

"Garn" is German for Yarn, another package manager in the JS/TS ecosystem.

"Nix" (this is probably known by now) is a German/Dutch term for "nothing".

"Garnix" in combination would colloquially be "really nothing [at all]".

I am thrilled to hear that this effort exists.

What’s the rationale for the heavy use of tagged template literals in the API? From the outside, it seems like an esoteric choice that makes ergonomics slightly worse, less approachable, and less idiomatic. This seems to fly directly in the face of the goals of this project.

All that said, I could be convinced that the API choice isn’t a mistake.

At any rate, I’m excited to see where this project goes.

It’s to allow interpolation of packages and environments. But in practice we don’t use it that often, so we were thinking of switching the main function to using just a second string argument. (In other words, I agree.)

That seems reasonable! I can’t really locate any examples of that functionality. Could you show me what that would look like?

One working example is this:

  import * as garn from "https://garn.io/ts/v0.0.14/mod.ts";
  import * as pkgs from "https://garn.io/ts/v0.0.14/nixpkgs.ts";

  export const main: garn.Executable = garn.shell`${pkgs.jq}/bin/jq --version`;

Put that in a 'garn.ts' file and run 'garn run main' and you should see the version of 'jq' that you can get from our 'nixpkgs' module.

But yeah, I completely agree with the sentiment here. This is a rather cumbersome syntax to support a use-case that we don't even have examples for. So clearly the normal usage shouldn't force you to use template strings.

I can definitely the utility of it.

Perhaps a standalone function (like nixRaw) could work to enable this.

I really like Guix & Nix, but I can see the appeal of this.

Language familiarity, first-class IDE experience, and TS's type system.

Bringing `any` to Nix isn’t an improvement

Great to see this. I've been interested in Nix for a long time, but have never been able to really commit to it for many of the reasons called out in the blog article. Garn seems like it could be a major improvement. Looking forward to trying it out.

Such an exciting project.

Nix truly is a game changer, but the UX is not getting better in any meaningful way. I do think it will be a fantastic foundation for an abstraction layer on top.

Note: for anyone else trying Nix but bouncing off of it (especially flakes), Home Manager is where I'd recommend starting.

It lets you declaratively manage all your packages, home files, shell configs etc from inside a single text file, using Nix derivations. Without having to deal with much Nix language or its shell interface

Home Manager and nix-darwin was the gateway drug for me. Now I have a flake based setup that manages nix-darwin as well as my NixOS home servers.

Spinning up a new Mac takes minutes, Linux server most time is deciding if there are any unique packages/config just for it. Everything else the same.

Love it.

Some notes from a Nix fanboy:

> Currently go, npm, and haskell projects are supported.

Implicit here is that you're missing out on one of Nix' strengths—that being how Nix-lang is a lingua franca for every ecosystem with a presence in Nixpkgs. I've never written or even seen a line of Pascal, but it doesn't matter because of the 'package' abstraction. I can build and/or install a Pascal program the same as any other.

> With Typescript, you get the full power of programming — the ability to easily factor out variables, to connect and abstract functionality, to reuse code, to write tests.

Nix-lang also has these, it's just FP rather than imperative. (Except unit tests unless you include Hydra or something.)

> [Nix has tech debt, such as] the somewhat cumbersome and inconsistent CLI interface. The garn CLI is a fresh start.

Nix also has this in the form of the "new" CLI a.k.a. Flakes a.k.a. nix3.

On the whole, I can see this being useful to someone trying to convert their coworkers from NPM to Nix, but not all that impactful in the field of Nix UX improvements. Nickel and co. are where the good ideas are coming from IMO.

I'm interested to know if this finally will help me to enter nix world, I tried so many times but failed.

My Nix origin story is like that. Tried nixos a few times, gave up every time.

Each time learning a little bit more.

Then just used nix-darwin as a Homebrew replacement for a while.

Then adopted Home Manager. Spent a day learning the Nix language, finally.

Tried flakes, couldn’t figure it out. Tried again later, cargo culting someone else’s config. Learnt the language again. Rewrote their config from scratch, from first principles, testing inside VMs.

This is where I’m at now. Don’t spend much time on it any more, just periodically add a package or tweak my config.

Works well enough for me now. And I basically never experience “everything broken after Homebrew update” any more.

(One of the `garn` developers here.)

Yeah, that's definitely the intention. If you end up trying it out, I'd love to hear how it went!

Have you thought about a GUI layer on top of that, named uberhaupt?

But maybe that would create too much overhead..

lol, no we haven't. That is hilarious though! We might steal that name for some future project.

I hope this will lead to more projects leaving yaml and people automcompleting their way to perfect configuration. Although VSCode for TS and Python does generate cryptic messages for type errors.

This is pretty cool.