I know the reason, I just took the opportunity of answering to a claude dev to point out why it's no panacea and how this requires consistent context management.
Real semi-productive workflow is really a "write plans in markdowns -> new chat -> implement few things -> update plans -> new chat, etc".
That explains why it happens, but doesn't really help with the problem. The expectation I have as a pretty naive user, is that what is in the .md file should be permanently in the context. It's good to understand why this is not the case, but it's unintuitive and can lead to frustration. It's bad UX, if you ask me.
I'm sure there are workarounds such as resetting the context, but the point is that god UX would mean such tricks are not needed.
I'm surprised this hasn't been been automated yet but I'm pretty naive to the space - the problem of "when?"/"how often?" seems like a fun one to chew on
I think Gemini 3 pro (high) in Antigravity does something like that because I can keep asking for different changes in the same chat without needing to create a new session.
I’m about 18mos into managing my macOS hardware with Nix. And I’m conflicted. It’s clearly a powerful system, and I’m still very noob at it. It’s not clear to me that it’s the right solution for macOS. I’ve not felt comfortable enough with it to roll it to Linux hosts yet. Or use its docker image maker.
Consistently through the 25.05 period nix-darwin and nixpkgs would fall out of sync. I learned not to `nix flake update` too often as a result. It’s amazing that rolling back is as easy as it is, and that’s huge, but if you squint and reason that mise and nix solve the same issue, why not use the less opinionated, easier to reason about mise?
As time has gone on, more and more of my system is managed via nix-homebrew … effectively producing a Brewfile for the vast majority of my package needs. Why not just use Brewfile directly?
I really want to advocate for nix, but it feels like I lose the “why not x?” conversations with myself, I can’t fathom winning them against a less invested peer.
This past month, I have spent a decent amount of hours (7+) trying to setup nix on my mac with nix-darwin, and failed.
Most tutorial out there encourage you to download someone else's configuration to get going. I don't want to do that. I want to understand at its core how this thing works.
I've read the official nix language documentation, watched YouTube tutorials, read 3rd party tutorials, and still couldn't get going with a simple configuration that would install a few packages.
The nix language is also really unpalatable to me. But I could deal with that if the examples out there showed a consistent way of doing things – that's not the case. It seems one same thing can be done many different ways – but I want to know and do it the right way. I would generally turn myself to the official best practices documentation, except nix' is very short and doesn't help much.
I really want to use nix. There's no question about its advantages. But nix just won't let me (or maybe I'm too old to learn new things).
That being said, I'll probably give it another try this month...
> The nix language is also really unpalatable to me.
yeah, I wish I could give you some "it gets better" good news, but...
I've used NixOS as my daily driver for ~10 years, including the laptop I'm typing this on.
I love NixOS-the-OS, I love nixpkgs-the-ecosystem. but I still hate Nix-the-language.
it's like Perl and Haskell had a drunken hookup that produced a child. and then abandoned that child in the forest where it was raised by wolves and didn't have contact with another human until it was fully grown.
(to answer the inevitable replies, yes I understand functional programming in general, and yes I am aware that Guix exists)
for simple NixOS administration, you can get pretty far with treating configuration.nix as "just" a config file, rather than a program written in a Turing-complete functional language.
writing your own modules or flakes, or re-using flakes published by other people, is strictly optional. make friends with The Big Options Page [0] - anything you find there can be dropped into your configuration.nix without really needing to understand Nix-the-language.
> The nix language is also really unpalatable to me.
It may not really help the case, but I firmly believe that it is not the language, but the ecosystem, and is more of a fundamental issue. But maybe putting the blame elsewhere could help accept the situation.
So anyways, the language is pretty much a lazily evaluated JSON. But even if it were something else (insert your favourite language), the problem ultimately is that packaging software is complex especially in a non-standard way, with endless edge cases, requires whole libraries and conventions and this is simply not a well-trodden path. Most programs simply hard-code "traditional" Linux file system conventions and those have to be patched in some way.
So the hard thing is not "is this really a function application here", when writing new Nix code the hard thing is simply knowing that for python there already exist this abstraction in nixpkgs, but to use it you need this folder structure and this build tool, etc. Especially when there are multiple abstractions for the same thing because it's an absolutely huge repository with countless packages.
But the benefits absolutely make up for it big time - there is simply no going back from Nix imo. I would honestly feel constantly "dirty" with any other traditional package manager, it's like file "versioning" before version control.
(PS: just grep for use cases of a function you are looking for. Also, find a "blueprint" package and start from there, e.g. another program written in python with a few native deps)
I've used Nix for at least seven years, and I firmly believe that the language is a large part of the problem. Yes, the Nix language is "just another lazily-evaluated pure FP language in the ML tradition" and "it's like a lazily-evaluated JSON", but it has several large footguns. The biggest one is that spaces are use to separate elements in list literals as well as for function application. The second is the lack of a usable type system, in the sense that the programmer cannot assert the types of values in a useful way. Instead, you have to rely on comments and convention to know what a function's arguments are.
These two design warts also interact with each other really badly: If you try to put a function application into a list and forget to enclose it in parentheses, you instead insert the function as one element in the list and its arguments as successive elements. The usual result is "expected an X but got a function" error in some completely unrelated part of the code.
It is the language. The module system is both semantically indispensable and a second class citizen. It's another language, implemented on top of Nix. Once you have a userland "if" reimplemented in your language you know you're in a bad place. (`mkIf`)
Maybe lazy evaluated attrsets can help make a dent, but still the lack of static types for module code is beyond painful. It's hostile.
I believe Nix is worth it in spite of this, and I'll advise anyone to learn it, it truly is the way forward, but by god do I hope it's not the last step on this journey. Please, Lord, please don't let nixlang be the final iteration XD
I read the same complaint about the language from people I follow who love and actively promote Nix. So it's not just you.
Sorry for adding to your frustration of "just follow what someone else did" but I recently went all-in on managing my Mac (programs, dotfiles, configs, etc) via Nix* when setting up a new machine recently. https://github.com/landaire/config/tree/main/modules
*Nix + homebrew, mostly because Homebrew packages more macOS applications.
I've been on a similar journey this past month, although it sounds like mine went a little more successfully. I've managed to get a repo setup which contains a nix flake with nix-darwin configuration, and it also calls into some home-manager modules which I also use on a linux device as well. I do agree, the nix language isn't particularly to my taste either.
I know you're hoping to go from first principals but I'm happy to share the repo if you want (email in my profile).
Aside from that, what issues did you run into? I'm keen to know if I've just not gone deep enough and will soon hit something.
I had the same reaction my first year. I found the NixOS documentation to be very poor and the lack of a single set of best practices (e.g., imperative, declarative, home config, flakes) to be frustrating.
I switched a couple devices to Guix and was at first encouraged by their much better docs, but the lack of features and battle testing has been a problem with longer use.
I've mostly been happy to go back to NixOS thanks to LLMs. Even a year ago, AI was very good at updating Nix configs and fixing any errors. Ideally Nix would have better docs and a more intuitive unified config system, but LLMs have made it usable and the best solution for now.
I struggled with this too and it took me a while to accept that there is no right way. There are many ways, and there is a lot of legacy style out there, but ultimately you have to do what works for your own productivity/sanity.
you should look into learning how to write modules. nix-darwin at its core is a somewhat underbaked port of nixos to mac OS with the same very useful module system. otherwise look into just getting home-manager working and working your way up.
I'm not conflicted. Nothing compares to nix. I've been using it on macOS, for Linux hosts, for years now, and it's been incredibly rock solid. I stopped using homebrew years ago and I couldn't be happier about that.
> Consistently through the 25.05 period nix-darwin and nixpkgs would fall out of sync. I learned not to `nix flake update` too often as a result.
I find using a singular nixpkgs version is almost always a recipe for things breaking if you are on unstable. I usually end up juggling multiple nixpkg versions, for example you might want to pin the input to nix-darwin separately.
This is squarely a nixpkgs problem. It's the largest most active package repository known to man. I am pretty sure GitHub has special-cased infrastructure just for it to even function. Things are much more stable in release branches. If that causes you pain because you want the latest and greatest, it's worth considering that you'd experience the same problem with other package repositories (e.g. Debian), and then asking yourself what it is you are actually trying to accomplish. There's a reason they call it unstable.
> but if you squint and reason that mise and nix solve the same issue, why not use the less opinionated, easier to reason about mise?
If mise works for you then great, use it. When I squint and reason, they do not solve the same issue. I don't know how you come to the same conclusion either. Why are you using nix-darwin at all? What is the overlap between nix-darwin and mise? I don't see it.
If all you want is dev environments, I recommend flox.
At the end of the day I'll continue using nix, and especially nix-darwin, _solely_ because it let me set up a new machine in under 5 minutes and hit the ground running. Nothing else compares.
I got here through devenv, I was fully bought in on its proposal and once I found its edges I started peeking under the covers to understand how it worked.
At that point I was pretty deep in mise for everything that wasn’t using devenv. This perhaps help frame why I see them solving the same problem.
I definitely had my “aha!” and ditched mise because nix seemed it had solved my problems. But now, in a new gig, I’m running into lots of edge cases that mise could solve at the drop of a hat and nix (/ my poor understanding of the fundamentals) struggles with.
So, with that all said, I suppose my point is that you get a lot of overlap between the two, and mise is easier to use and get buy-in on. There are certainly elements I find appealing about nix which mise doesn’t touch (promise of repeatable builds, the entire package ecosystem, etc), however.
I similarly found `nix flake update` frustrating for a while, especially when using unstable Nixpkgs. I wrote a tool called `npc` that basically solved the problem for me by letting me bisect whatever Nixpkgs channel(s) I have in my flake inputs: https://github.com/samestep/npc
I've only barely used Nix on OSX to manage packages and I thought it felt awkward at the time. But I had also barely used NixOS at that time. Today I'm happily running NixOS on my NAS and my "gaming" desktop. My son is running it for his desktop as well. What feels awkward and fragile on OSX is far more stable on NixOS. But you do have to learn some of the Nix syntax and ways of doing things which it sounds like you're already getting some of on OSX. The reason I'm going to use it on OSX again is mostly to get consistent HOME configuration and tooling across all of my devices. I'll manage my OSX home dir and tools with the exact same file across multiple computers.
My principle of adoption was essentially this but in reverse; use it on the system I use the most (macOS), learn, and then use my niche knowledge to apply it to less frequently used computers like my gaming rig.
Along the way I acquired enough talent that use at work seemed reasonable.
As time has gone on, however, I have found things like the stringent need for everything to be built results in archaic packages versions in nixpkgs, etc., while core waits to bump the rustc version. Thus my return to using brew for almost everything albeit managed via nix-homebrew.
Case in point: I use zed, which relies on cutting edge rust features, which nix cannot deploy because of stability concerns. Everyone is right in this situation, but that left me with an archaic version of zed until I moved to the homebrew version.
Could you clarify what you mean regarding Zed? I checked just now and it looks like Nixpkgs had the latest version 0.214.7 within 24 hours of its release: https://github.com/NixOS/nixpkgs/pull/466449
About 4mos ago I moved to using brew for zed because at the time there was some hard block on updating rustc in nixpkgs-stable to a version which included some feature that zed relied upon.
I have both Nixos and Macs so I appreciate I can control everything through a single repo. I have a single flake with nixosConfigurations, darwinConfigurations and home manager pointing to different nixpkgs and other weird stuff such as jovian for my gaming pc and a special repo for my rpi5.
In practice nix-darwin relies on being a drop in, which means maintaining compatibility with api surface which in the proper nixpkgs world is a closed loop. There are several cases of this breaking since 2020 or so.
Notes on how I worked around it for the time it was broken:
> To work around it on myside I tried various things. Fundamentally I rolled back to nixpkgs-24.11-darwin which needed corresponding changes to nix-darwin (nix-darwin-24.11) and home-manager (release-24.11) to get everything working.
Heat conduction requires a medium, but radiation works perfectly fine in a vacuum. Otherwise the Sun wouldn't be able to heat up the Earth. The problem for spacecraft is that you're limited by how much IR radiation is passively emitted from your heat sinks, you can't actively expel heat any faster.
There is some medium in low Earth orbit. Not all vacuums are created equal. However, LEO vacuum is still very, very sparse compared to the air and water we use for cooling systems.
Hot objects emit infrared light no matter the conditions. The hotter the object, the more light it throws off. By radiating this light away, thermal energy is necessarily consumed and transformed into light. It's kind of wild actually
Same, fortunately my local shooting range has a good selection of firearms to try. I tried the P320 and P365. I had been considering the P365, but it was so snappy I reasoned the otherwise completely boring P320 would be a better fit for my needs. However, it was close enough to another firearm I own that I decided to cool-off and see if I still wanted it in a month... then this all broke.
My girlfriend has a P365X. I wouldn't touch a P320 with a ten foot pole, but the 365 and its variants have proven pretty reliable for many people. It is definitely snappy though, but most "subcompacts" are, because physics.
They can freeze funds and cancel future contracts, which should be enough pressure. What's wild to me is the military version was not even remotely safer.
100% the families of those affected by Sigs goof ups should sue.
I found the syncing process in chezmoi to be so hard to mentally model.
I’d often change a file, forget that it was backed by the chezmoi store, later find myself trying to reconcile the differences, just so I could commit and share w/ another computer. nix + home-manager and snowfall lib, once over the multi month ramp up, have been such a breath of fresh air in multi system management
I ended up writing some pretty hacky elisp to automatically load my chezmoi templates if I try to edit a Chezmoi-managed file. It'll also handle applying and pushing saved changes to my git remote so I don't forget that either.
It makes me feel bad because I frequently will search github with "language:nix" to find usages, which is usually done in someones (sometimes the nixpkgs commit authors) personal config :')
Hey now. America is a broad spectrum of people — some of us are heretical and believe governments have a role in everyday life, some of us believe the opposite.
If you only ever look at the way a system works at a specific point in time you only observe it at that point in time.
America has had multiple attempts at solutions for healthcare over the years, each started with good intent and then waylaid by various causes to produce what we have right now.
A sibling comment mentions political compromise to pass the ACA, as an example of this.
Another example is that HMOs were started with inherent goodness, but got “corrupted” (in my mind) by profit seeking.
To directly answer your question: a core tenet of the Republican tent is minimal government involvement in day to day lives of the citizenry. Ergo, the Swiss system won’t work because it involves a lot of bureaucracy. Republicans link bureaucracy to cost, and feel this is not an appropriate use of tax payers dollars.
The holes in this political doctrine are not part of my answer here fwiw. Please no “but…” comments to that end :)
To be fair the tenet is minimal involvement in the day to day operations of the economy and maximal involvement in the day to day lives of the citizenry.
I do find the ironies in political platforms quite beautiful. I also love how they provides endless fodder for largely fruitless internet discussion ^_^
For counter argument sake, if a highly regarded company says: “we’re going in a hiring spree”, all of that available talent adds 50% to their comp ask.
Broadly speaking though, I think you’re experiencing confirmation bias to some degree. If you only look at companies that are on the struggle bus, then you only see a limited number of levers that management has (RIF, delay CapEx, etc). Other struggling companies that don’t take evasive maneuvers go out of business and we don’t hear the story.
I think you may be observing context rot? How many back and forths are you into when you notice this?
reply