Maybe Nix is pretty niche (though getting bigger -- I've heard several "hey this seems like something we should look at" type conversation about it at my very technically conservative company) but emacs is very, very old (predating Linux even) and definitely not "trendy." If anything, the perception on the mailing lists is that emacs is on the way out unless a new generation of users/maintainers can be recruited.
How many people in 2023 browse/dedicate time to mailing lists?
I'm not trying to pick on anybody or make fun of anybody and say "oh my gosh you have too much free time on your hand". I don't really know what I'm trying to say. It's just interesting to me.
The author did a very nice thing sharing their experience with the world for others to benefit and I am grateful. I am just zooming out a bit more macro and saying "who outside of the software community would understand dedicating hours to a blog article that may or may not help others on ________" where ______ is relatively fringe technologies.
What does this blog article offer that Nix documentation/examples doesn't?
A hobby's not a job. It doesn't have to be a good time investment, or healthy, or relatable, or ... If it makes you happy when you do it, that's good enough.
I wrote that's is healthy to have them, not that they need to be healthy activities. If you only do things where you're interested in investing your time, or improving something, that's a possible path to burn out. It's nice to do useless stuff with no expectations too.
The OP appears to be student and software engineer that is employed writing F# and Nix, and made the blog purely as an outlet to document the things they are interested in (and good on them that).
>How "fringe" can I be. How niche of technologies can I use. How deep down a rabbit hole can I go avoiding mainstream "technologies".
As a Nix user, I'd say this is the wrong characterization. It's not about being niche, bikeshedding, or yak shaving. It's just about getting as close as possible to perfection.
> It's not about being niche, bikeshedding, or yak shaving. It's just about getting as close as possible to perfection.
Did you mean to write "getting as close as reasonably possible to perfection"? Because getting as close as possible to perfection absolutely does involve bikeshedding and yak-shaving; that's why the saying "perfect is the enemy of good" exists and why people are generally advised to avoid gold-plating.
You just wrote a multi-paragraph post about how someone’s hobby is a waste of time, which is ironic, because surely writing that post was just as much a waste of your time.
Why would it take any more time than learning and dealing with "mainstream" technologies? I've wasted far more time on Docker proportional to the use I've gotten out of it compared to Nix or Emacs!
I'm not sure I see your point. Nix is cross-platform, emacs is cross-platform, and make is cross-platform. With the exception of Nix, make and emacs have been in use by many, many shops for decades. It just doesn't get talked about much because they're long past being considered fun and sexy.
I've used Nix at my last 5 jobs. It's how I learned it (mostly as a build tool and package manager). I also started to use NixOS for my desktops after using NixOS for server config at a few of those companies.
emacs isn't hipster imo. Maybe some people treat it as such? But I learned it in university when I was learning to code in C and Scheme and never looked back. It's always been the boring choice.
I'd say they are very practical choices for a specific type of person who likes principled software and hacking.
Nix is not a "required skill" by any means, but it fixes a very annoying problem that you may-or-may-not face related to dependency conflicts. NixOS also has atomic updates.
I think calling it hipster is a bit odd. Its not like I would say Java is a bad tool because I don't use it for embedded stuff. Java is fantastic for enterprise and even start up contexts.
Similar arguments can be made with emacs. Its a text editor, and you can do a bunch if stuff with it. Vim is also good. Jetbrains is also good. There's a bunch of other good ones. It probably depends on what you're doing. It'd be a more meaningful discussion if you defined a problem space.
I probably would have ignored your post of it wasn't for the TikTok comment. Nix useage is sort of thoughtful-by-design, which is antithetical to TikTok use. Rubbed me the wrong way.
For me it started in university when I had more unstructured time and continued post graduation because I found it more interesting than most TV, video games etc.
Feels surreal to see “normies REEEE” type sentiment applied to old-software hackers on a hacker forum :P
Hi, I use Nix and Emacs at work. I have, at points in the past, promised to write a blog post about how we use Nix.
It's not about being hip or fringe. Nix solves problems we have. And we're not the only ones. The founder of Hashicorp puts it this way:
> I'm actively trying to work through my Nix God complex. It's been so long that when I see non-Nix users complain about issues getting software to run, I'm truly confused. It's like someone looking at a river lamenting about having to ford it while I'm riding a bicycle on a bridge
Nix isn't ready to be mainstream yet. That doesn't mean you should talk down to those who are working towards that today. It is entirely possible that you may end up working with it yourself in due time.
I'm very new to make(1), but became a fan quickly.
Rather than maintaining documentation that inevitably gets out of date, if a project has a Makefile, it self documents the build process, language independently. No need to read a README to see if people are currently using yarn or npm, or find external documentation on a build tool you haven't used before; the Makefile shows the targets and what commands they run.
Here you assume that more people know about make than npm or yarn, which I wouldn't bet on.
Besides, I would guess that every JavaScript developer when jumping on the new project will know how to use npm, just like every Java developer would know enough maven, and adding some supposedly general standard tool on top of already standard tools in that area wouldn't help.
True, but maybe 1% knows make. And since many of them run Windows, many don't even know how to install the correct version of make on their development box.
Just my opinion but make is still the best ci/cd tool. I see way too many places with layers of tools and yaml configs and hosted cvs pipelines (that you can't easily recreate locally), when a make file would do just fine if not better.
It's very, very convenient to have your CI/CD yaml just trigger make targets. Still get the benefits of everything running on Someone Else's Computer, but mostly-to-100% reproducible locally for debugging.
The tradeoff isn't just about documentation, but complexity. A tedious, manual build process is still tedious and manual if it's self-documenting, but a more streamlined build process without as much documentation might still be less of a burden overall. It's also not like Make doesn't have its own thorny edges too; one person's self-documenting use of a feature is another person's inscrutable magic invocation. If you're working on a team project and already require a certain level of expertise in the ecosystem you're using, it's arguable that using the native build system (warts and all) will be a better tradeoff.
Obviously you haven’t seen > 100 line makefiles. They are a mess to understand and I have no interest in wasting my time to understand what they are doing.
I have also been using make for the past few years, and since then whenever I jump on a new project, right away I get the readme and commands needed to do stuff with a project, and put them in a Makefile, and people start loving me right away. It's baffling to me how easy but ignored is make and how people accept to write / remember un-mnemonick commands without looking for alternatives/solutions
For C(++), I use make and ccache. I can just use `find` to place a naive dependency of every header file on every C file; and, `*.d` files (from clang/gcc): I get nearly perfect incremental builds, without file updates breaking the build, in parallel. Totally bulletproof and works on all the Unixen I care about (Linux, macOS, BSD).
I see what you say, and also understand the amount of time / boredness you save with this simple setup, that between us, is simple simple no? But you go around and people maybe stay at the PC waiting for compilation forever and accept to wait forever, despite that being one search/doc read away.. it's really baffling.. and keeps me thinking now maybe it's that the reason why people consider linux/bsd hard non-user friendly systems, because it's either you throw the solution at them, or they would just ignore how simple is something and how would change their productivity / workflow by orders of magnitude
I had a makefile a while ago that would incrementally build docker containers based on containers metadata (for the dockerfile content hash) and would update those changed automatically, and it took like 2 minutes, instead of complaining while waiting, it's crazy how much simplicity is just ignored
Yeah but it's like a good reasoning valid for just about everything, like code that is undocumented or abandoned because people have left is just as bad, but that doesn't make us stop writing applications? Everything is good or bad depending on developer's attitude.. I don't really feel your point specific for Makefile or as discouraging about Makefiles..?
It does (or should) make us write less code if possible;)
Not arguing makefile has value but I worked on legacy projects with makefiles that break in mysterious ways and in those cases I would take the same stuff with hows and whys spelled out in plain English instead!
Make is one of the best tools I've ever come across, but with one big caveat that none of your files must have spaces on their names or all hell breaks loose. Seems like a reasonable trade off to me :)
IIRC, "spaces in file paths breaks programs" is explicitly why Windows uses "Program Files" as its default installation path; so that programs would be written with robustness to that.
> Files with spaces in the name are just a bad idea anyhow
It's only a bad idea because of assumptions programmers make about file paths not containing spaces that they then build into their code and cause problems.
The Mac (and user-friendly file names that contain things like spaces) has been around since 1984. Why has it taken this long to just accept that file paths might contain spaces? Is it just because (essentially) Bash is a huge pain about quoting?
The only thing keeping people making this assumption is inertia and the only way to change inertia is by leaning into it. I like documents named "Paper about Nietzsche.doc", not "Paper_about_Nietzsche.doc" and directories named "Party Photos" over "Party-Photos" etc.
It's about the user aesthetics, not the ease of the coder.
A better questions is why don't we have a files system that forbids spaces in file names entirely. Then programmers assumptions and reality will match, and much will be simplified.
Because spaces in the names of things are _human_. Would you like to type your full name as Patrick_Lastname everywhere? Or have it canonicalized to that?
I'd much prefer if the space was encoded somehow like with URL encoding, or just make underscore and space interchangeable.
> Files with spaces in the name are just a bad idea
Hear, hear! I would love a mount option that disallows them for good (or replaces them transparently by nbsp U+00A0).
Do people also want variable names with spaces in their programs? Filenames are variable names, and the file contents are the data that the variable refers to. Allowing spaces in variable names is just brain damage.
Is this an issue of make, or shell? If we properly quote all variable usage, shouldn't it simply result in quoted values in shell commands, which are then correctly interpreted? Or do you mean when using something with spaces in make in-built functions?
I can't tell if you meant to imply this, but that is the very benefit Nix provides: a guaranteed stable and sterile environment where ./configure, make all, and make install can be run. No more chances.
If you have a configure step it can fail by default if there is anything to specify explicitly. But otherwise it is nice to have some defaults. In my opinion a configure script shouldn't do much in terms of detection. It should not silently enable/disable features based only on libraries being present/missing. By default it should try to use lib a and b, if the user wants they could explicitly opt-in to use lib c without lib b, otherwise let it fail.
That said it all makes it easier to just use config for make that can be edited. For example config.mk included by Makefile. I learned this trick from Suckless.
Using `make` with `.PHONY` targets is what I'd call a "task runner". -- In NodeJS, a package.json's "scripts" serve a similar task.
I think the main/only reason to go out of your way to use `make` as a task runner is its ubiquity.
However, if you're already using nix, it's probably not much of an issue to use a better task runner.
I'd recommend 'just' instead https://github.com/casey/just -- It has a nicer UX, with a few significant quality-of-life improvements out-of-the-box compared to `make`. e.g.
- you can get a list of tasks, and select one using `fzf` with `just --choose`.
- can inline use of bash, or python, etc.
- `just` automatically searches up a directory tree for a `justfile`.
NPM has no concept of dependencies of steps like make has for what people use in "scripts". It is painful to see people doing that all the time and then constructing their commands as long strings, which the tool they use has no knowledge about, using recursive invocation and having to write "npm run" again and again in those long strings, while in a Makefile it is all figured out automatically, as dependencies of steps are clearly stated as such.
It feels akin to handling HTML as a long string and fumbling around in it, as was done in the past in many PHP projects, instead of handling HTML as structured data, an XML tree or similar.
NPM package.json scripts is a Makefile for the very poor. Yes it can be used like that. Should it? When commands start to have prerequisites probably not.
For projects where you need to collaborate with others, yeah.
For personal projects like "how I generate my static site", and where you're already using a tool like nix, 'tool already installed' isn't worth going out of your way for.
Right. For personal projects, once you're using Nix you're really free to prioritize basically anything else over package availability. That's one of the joys of it!
Once you build a docker image, you can distribute that artifact reliably. But building docker images is highly error prone, at the mercy of non-determinism, various failure modes of package managers, and mutable state from web servers you don't control. In practice, you can't depend on it working without active maintenance and disciplined usage.
With Nix, if it built once, it will build again, consistently and deterministically. It reduces fear of changing things because it just works. You don't have to cross your fingers and hope the build succeeds this time.
What smilliken said. Essentially, with a single flake.lock file, you get build determinism, which is huge. Docker cannot guarantee that... which is, in fact, why distributing Docker images is a thing, instead of just distributing and composing Dockerfiles.
If Dockerfiles were guaranteed to succeed, and Docker hosted a cache of hashed binaries instead of a cache of Docker images (the former is far more efficient than the latter, btw), then all you'd need are Dockerfiles.
Enter Nix (and its flake.nix/flake.lock files).
Nix essentially solves a problem that Docker can't by treating a build as an immutable function with binary-hashed inputs and binary-hashed dependencies and completely controlled environment variables (with a few exceptions and special cases)
There is a one-time cost of building (or downloading) the Nix derivation's binaries. But then it is a native binary. With Docker on Mac, the cost continues.
Using nix develop (without -c) to get a development shell has some advantages over docker. It layers over your existing environment (unless you don't want it to) so you can still access things like git from the same shell. With docker you either add it to your build deps or do some stuff inside docker and some stuff outside.
It also builds your environment on demand rather than having to manage the two step thing of building the image and then making sure you're using the right one.
I've found this much more flexible and convenient than anything with docker.
I use make and GNU Guix. Quite similar. You take make as a task runner and a dependency manager/package manager as a means to construct a reproducible setup for a project.
Definitely agree that Make and Nix is a nice combination, especially for facilitating faster development like the `hugo serve` use case.
I'd also argue it makes your code overall less volatile. If you ever wanted to build your code outside of Nix for whatever reason (such as migrating to another reproducible packaging tool), having everything in unopinionated `make` is a whole lot easier. Plus, it leverages the advantages of a tool that is dedicated to building code.
84 comments
[ 3.5 ms ] story [ 142 ms ] threadHow many people in 2023 browse/dedicate time to mailing lists?
I'm not trying to pick on anybody or make fun of anybody and say "oh my gosh you have too much free time on your hand". I don't really know what I'm trying to say. It's just interesting to me.
The author did a very nice thing sharing their experience with the world for others to benefit and I am grateful. I am just zooming out a bit more macro and saying "who outside of the software community would understand dedicating hours to a blog article that may or may not help others on ________" where ______ is relatively fringe technologies.
What does this blog article offer that Nix documentation/examples doesn't?
Those are hobbies. It's healthy to have them. Some people like to run, some play musical instruments, some poke around non-mainstream software.
I wrote that's is healthy to have them, not that they need to be healthy activities. If you only do things where you're interested in investing your time, or improving something, that's a possible path to burn out. It's nice to do useless stuff with no expectations too.
Why should they be at a specific place? Maybe their life goals are different than yours? Are they enjoying their current lives?
> How far off is writing a blog article about Nix + make?
Likely a bit further away in terms of creativity / time commitment. But I'm not going to judge either. Let people enjoy things we don't like/get :-)
Why would you (personally) try to assign your values to someone else's hobbies? Is this your own hobby?
> How many people outside of the software community would understand/relate to this type of hobby?
I don't understand the relevance of this, and am now trying to figure out now if all responders on this thread have been successfully trolled...
Film at 11.
https://glorifiedgluer.com/about
The OP appears to be student and software engineer that is employed writing F# and Nix, and made the blog purely as an outlet to document the things they are interested in (and good on them that).
As a Nix user, I'd say this is the wrong characterization. It's not about being niche, bikeshedding, or yak shaving. It's just about getting as close as possible to perfection.
Did you mean to write "getting as close as reasonably possible to perfection"? Because getting as close as possible to perfection absolutely does involve bikeshedding and yak-shaving; that's why the saying "perfect is the enemy of good" exists and why people are generally advised to avoid gold-plating.
emacs isn't hipster imo. Maybe some people treat it as such? But I learned it in university when I was learning to code in C and Scheme and never looked back. It's always been the boring choice.
I'd say they are very practical choices for a specific type of person who likes principled software and hacking.
I don't blog about either of them though :)
I think calling it hipster is a bit odd. Its not like I would say Java is a bad tool because I don't use it for embedded stuff. Java is fantastic for enterprise and even start up contexts.
Similar arguments can be made with emacs. Its a text editor, and you can do a bunch if stuff with it. Vim is also good. Jetbrains is also good. There's a bunch of other good ones. It probably depends on what you're doing. It'd be a more meaningful discussion if you defined a problem space.
I probably would have ignored your post of it wasn't for the TikTok comment. Nix useage is sort of thoughtful-by-design, which is antithetical to TikTok use. Rubbed me the wrong way.
For me it started in university when I had more unstructured time and continued post graduation because I found it more interesting than most TV, video games etc.
Feels surreal to see “normies REEEE” type sentiment applied to old-software hackers on a hacker forum :P
It's not about being hip or fringe. Nix solves problems we have. And we're not the only ones. The founder of Hashicorp puts it this way:
> I'm actively trying to work through my Nix God complex. It's been so long that when I see non-Nix users complain about issues getting software to run, I'm truly confused. It's like someone looking at a river lamenting about having to ford it while I'm riding a bicycle on a bridge
(https://twitter.com/mitchellh/status/1650201460234412032)
Nix isn't ready to be mainstream yet. That doesn't mean you should talk down to those who are working towards that today. It is entirely possible that you may end up working with it yourself in due time.
Rather than maintaining documentation that inevitably gets out of date, if a project has a Makefile, it self documents the build process, language independently. No need to read a README to see if people are currently using yarn or npm, or find external documentation on a build tool you haven't used before; the Makefile shows the targets and what commands they run.
Besides, I would guess that every JavaScript developer when jumping on the new project will know how to use npm, just like every Java developer would know enough maven, and adding some supposedly general standard tool on top of already standard tools in that area wouldn't help.
Many only know Gradle.
True, but maybe 1% knows make. And since many of them run Windows, many don't even know how to install the correct version of make on their development box.
Still those ci/cd configs should always be very thin wrappers (single command for single thing) around whatever script tooling is used internally.
They're not that hard to understand and follow.
I had a makefile a while ago that would incrementally build docker containers based on containers metadata (for the dockerfile content hash) and would update those changed automatically, and it took like 2 minutes, instead of complaining while waiting, it's crazy how much simplicity is just ignored
Not arguing makefile has value but I worked on legacy projects with makefiles that break in mysterious ways and in those cases I would take the same stuff with hows and whys spelled out in plain English instead!
https://www.samlogic.net/articles/program-files-folder-diffe...
It claims we have localised names in Swedish. I have literally never found a computer that have those. They're always named in English.
It's only a bad idea because of assumptions programmers make about file paths not containing spaces that they then build into their code and cause problems.
The Mac (and user-friendly file names that contain things like spaces) has been around since 1984. Why has it taken this long to just accept that file paths might contain spaces? Is it just because (essentially) Bash is a huge pain about quoting?
It's about the user aesthetics, not the ease of the coder.
I'd much prefer if the space was encoded somehow like with URL encoding, or just make underscore and space interchangeable.
Hear, hear! I would love a mount option that disallows them for good (or replaces them transparently by nbsp U+00A0).
Do people also want variable names with spaces in their programs? Filenames are variable names, and the file contents are the data that the variable refers to. Allowing spaces in variable names is just brain damage.
This means that we lose the non-Nix build processes, but I get to keep the best of both worlds, and don't have to run `nix shell` or setup direnv.
"Uhm, actually" I use Guix, but the idea is the same:
Or without an external manifest: This is equivalent to the common shebang trick: Or just invoking Guix inside the recipe: Depending on the complexity of `export.el` (< 5 lines?), I'll often keep that inside the Makefile too; the less files, the better!But I get it if one wants that file available to call from elsewhere.
And there you have it: the fundamental problem. What if I want to port your package to Nix?
In practice, I'm sure it's doable, but you are introducing a lot of overhead and complexity by putting that work into that place.
./configure
make all
Will actually have a good chance of working, which is not something my makefiles can live up to!
That said it all makes it easier to just use config for make that can be edited. For example config.mk included by Makefile. I learned this trick from Suckless.
I think the main/only reason to go out of your way to use `make` as a task runner is its ubiquity.
However, if you're already using nix, it's probably not much of an issue to use a better task runner.
I'd recommend 'just' instead https://github.com/casey/just -- It has a nicer UX, with a few significant quality-of-life improvements out-of-the-box compared to `make`. e.g.
- you can get a list of tasks, and select one using `fzf` with `just --choose`.
- can inline use of bash, or python, etc.
- `just` automatically searches up a directory tree for a `justfile`.
It feels akin to handling HTML as a long string and fumbling around in it, as was done in the past in many PHP projects, instead of handling HTML as structured data, an XML tree or similar.
NPM package.json scripts is a Makefile for the very poor. Yes it can be used like that. Should it? When commands start to have prerequisites probably not.
You still don't get to define output files as dependencies, so it's not quite Make, but it's really not that bad if your project is already node/js/ts
In fairness, that's a pretty big reason.
For personal projects like "how I generate my static site", and where you're already using a tool like nix, 'tool already installed' isn't worth going out of your way for.
Has anyone compared these two approaches?
With Nix, if it built once, it will build again, consistently and deterministically. It reduces fear of changing things because it just works. You don't have to cross your fingers and hope the build succeeds this time.
If Dockerfiles were guaranteed to succeed, and Docker hosted a cache of hashed binaries instead of a cache of Docker images (the former is far more efficient than the latter, btw), then all you'd need are Dockerfiles.
Enter Nix (and its flake.nix/flake.lock files).
Nix essentially solves a problem that Docker can't by treating a build as an immutable function with binary-hashed inputs and binary-hashed dependencies and completely controlled environment variables (with a few exceptions and special cases)
It also builds your environment on demand rather than having to manage the two step thing of building the image and then making sure you're using the right one.
I've found this much more flexible and convenient than anything with docker.
I'd also argue it makes your code overall less volatile. If you ever wanted to build your code outside of Nix for whatever reason (such as migrating to another reproducible packaging tool), having everything in unopinionated `make` is a whole lot easier. Plus, it leverages the advantages of a tool that is dedicated to building code.