Usually I find the hype is centered around creating software no one cares about. If you're creating a prototype for dozens of investors to demo - I seriously doubt you'd take the "mainstream" approach.
Always sounds so interesting and then I do a search only to found out it's another product trying to sell you your 20th "AI credit package." I really don't see how these apps will last that long. I pay for the big three already - and no I don't want to cancel them just so I can use your product.
This is a valid observation. I wonder though if people who have been coding for decades, but choose to use AI assistance, would fall under the same AI slop category. It’s an interesting dilemma because the overwhelming amount of content getting posted just ends up breeding a ton of negative feelings towards any amount of AI usage.
It will if you let it. The number of times the AI has come up with 'I can write you 'x', 'y' or 'z' in a heartbeat, just say the word' and I keep on having to steer it back to the track of being a repository of knowledge rather than an overeager very junior co-worker that can't help themselves to want to show off their skills.
It's very tiresome. Like an idiot/savant, they're an idiot most of the time and every 10th try you go 'oh, but that's neat and clever'.
Yeah, we've been here before. Empires don't necessarily fall by the hand of their enemies as much as they fall by their own hands and hubris. See: UK, Germany, Russia, historical China and other asian countries, hell even the Romans, and so on and so forth, we've had it all. Trump is nothing new, just another fool in a long line of fools.
It is getting downvoted because it is a well known silly trope. Generally, success reinforces itself. That’s why there have been a bunch of countries that have had multi-generational streaks of repeated success. Eventually, this feedback look can fail, but it isn’t on some predictable four generation pattern.
> Eventually, this feedback look can fail, but it isn’t on some predictable four generation pattern.
Actually, it kind of is.
See The Fourth Turning and any other book based on the Strauss-Howe generational theory.
Is this theory air-tight and inviolable? No. Does it more or less support this “silly trope”? Yes. I think it’s safe to say that it is directionally correct.
If you think that it's just an imagination, the universe will make you physically feel what it really is. Not all at once, but gradually, drop by drop. And then, you'll learn the true meaning of another "meme" word: ignorance.
This is what they want you to believe. You are useful and convenient when you are malleable (to someone's else agenda aka "their choice"). Ideally, you should not practice any discernment at all, raise no questions, silence any suspicions. As if it's all by sheer coincidence and predefined by external forces ("chance").
It's not the truth. It's an observation, one of many. It does not look neat, it looks horrible. However, I am ok to give it a deeper nuanced appreciation than to just negate it right off the bat.
Wow, this is literally the story of my team. Luckily there’s enough autonomy for us the escape the gravitational pull of the few remaining evangelists, but this is essentially what led us to this point.
I think that's kind of sad. There are a lot of good technologies that require some investment to understand them and a lot of worse is better approaches that end in a mayhem that is ultimately a terrible work environment.
For a while it seemed like investment would win but now I think we will have massive tombs of poorly written stuff that can only be worked around with even more LLM generated solutions. It is like the software bloat problem we've had recently but on steroids.
The most common answer I've seen is that Python packaging just "doesn't do it right" so it's impossible to get a clean Nix experience with them. Which, to some degree is true, but it also reveals the opinionated nature of Nix and why it often falls flat.
Welcome to the honeymoon phase. Mine lasted about a year. Eventually you will have to leave the comfortable area of "those who have done it before" and engage with some long, unwieldy, mostly undecipherable stack trace.
When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.
I think Nix is getting an unfair reputation for being too hard. Simple things are IMHO simpler in Nix than in any other distribution, and what one needs to know to accomplish them is tiny. It has basically reduced my sysadmin maintenance tasks to zero. In case of regressions, Nix makes it trivially easy to go back in time 2 or 3 years, cherrypick some packages and install them, or change your entire desktop environment, and then go back to the previous state with no effort.
Nix is hard if you need to build something difficult to package or something that has very unusual or dirty build processes. If you need to that regularly, Nix is not worth the effort unless you are an organization that values reproducibility and is prepared to pay for its cost upfront. If these particularly messy usecases are something that you don't encounter so frequently, you can always use an escape hatch to be able to make your install impure. For instance, distrobox is quite convenient to run e.g. an Arch or Ubuntu container. In my case, this has been helpful to run Julia, whose Nix packages are quite brittle.
I've been using Nix and NixOS since 2022. I can't imagine not using Nix at this point and agree that the reputation for "being too hard" is not quite accurate. Nix is different - that's the point.
The learning curve is a thing, although I'd argue that it's nowhere near as steep as the tools many of us use every day (C++, Rust, AWS/GCP, etc.)
Nix's "difficulty" IMO comes from defaults that are not sane and a split community. For example, if you use the official Nix installer, flakes are not enabled by default (despite being widely used [1]), but they are if you use the Determinate Systems Nix installer.
Flakes are realistically the only way to obtain the benefits that motivate learning Nix (deterministic pure builds, fine-grained control over dependencies) and are the "primary driver of Nix's adoption" [2]. AFIK there isn't a viable alternative to flakes other than maybe atoms [3], which are relatively new (like "lock files are totally hand made" new [4]). Yet, the official Nix stance on flakes is to wait... for... what?
For a day-in-the-life look at more of Nix's rough edges, I posted some rambles here [5].
Unless it becomes a typed language with clearer syntax around what is what, it’s painful at the scale of nixpkgs and nix without nixpkgs just isn’t all that useful.
I think the reputation is fair. Why is flakes still experimental, for example? That's a subtle bit of encouragement to do things the old way and as a result, documentation is always mixed and you end up "but how do I do that in a flake".
Something that is in theory nice is using the same packages in development and production. But "everyone" uses Mac OS for development and Linux for production, and if you want to guarantee that every developer on your team isn't recompiling Node from scratch, you want to use nixpkgs-25.05-darwin instead of nixos-25.05 on Mac OS. The result is that you aren't actually getting the same package across systems, which is rarely problematic but is something that Will Go Wrong someday. Why not keep Darwin stable in the main stable branch?
I have also found the entire system incredibly unstable during release pushes. Lots of stuff broke in 24.11 and unstable as 25.05 was being prepared (notably nodejs_20). What I learned from this experience is "don't touch package updates in May or November" which isn't amazing if you care about security updates.
So basically, Nix is incredibly rough around the edges. nixpkgs is a much better package repository than anything else I've used, but it's not perfect. It's generally more up to date than Debian unstable. It supports more platforms than Homebrew (which doesn't work on linux-aarch64, a platform I use heavily). Overall the philosophy of making each package entirely self-contained is the right approach.
NixOS is also fine, mostly... but I use Bazel to build all my personal projects. Bazel does not work well on NixOS. For some reason, nixpkgs doesn't have Bazel 8 which is the version I use (because if you don't update your project to a recent Bazel today, you'll have to do it tomorrow). If you get a NixOS-compatible bazel 8 from some random flake, you can solve that problem. But then there are a lot of assumptions the Bazel ecosystem makes, and those are unresolveable. To the Nix folks, having your build system download the official distribution of Go, verifying the sha256, and execing it to do your builds is unthinkable. Personally, I'm fine with it. The Go team knows how to release Go better than anybody. But this impedance mismatch makes it nearly impossible to have a project that builds on "normal" Linux and NixOS. You can go full Nix and get go, c++, etc. from nixpkgs, but then everyone has to have Nix before the can work on your project. I would be OK making that decision for myself (I already use Nix), but I imagine it's a hard sell if you just want to fix development at work. People would complain. People will run into problems. To some extent, this is Bazel's fault (and the ecosystem) for assuming that /bin/bash and some vaguely recent /lib64/ld-linux-x86-64.so.2 exists. NixOS says "no it doesn't unless you declare it and get it out of $PATH" but honestly which version of bash runs "exec bazel-out/program-that-was-just-built" is irrelevant in practice, so it's just an unnecessary barrier. There is an attempt at compatibility for those that don't care about versioning the version of Bash that each shell script runs (envfs, nix-ld), but at least for me, it doesn't work. All in all, the net result is that I can't actually do work on NixOS, and I can't write a flake so my home-manager configuration can install all the software I've written for myself, which is a pretty bad feeling. Building my projects is easy... "git clone git@github.com:jrockway/monorepo; cd monorepo; bazel build //jlog/cmd/jlog; cp bazel-bin/jlog/cmd/jlog/jlog_/jlog ~/bin". But it's literally impossible on NixOS simply because something in the 10,000 lines of other people's code wrote "#!/bin/bash" somewhere. That's pretty rough.
My TLDR is if you want the latest version of Git on Mac OS, linux-aarch64, and linux-x86_64, you should probably look at nixpkgs and home-manager. I like 'em. I don't think there's anything better. Everything else... it's rough. When you commit to leaning into Nix, a lot of your free time is going to disappear for a while.
For reference, I use Nix to manage three different machines, always via home-manager and nix-darwin (I left NixOS awhile ago and haven't looked back). I don't think it's "inevitable" that you'll hit the difficulty wall, but certainly likely.
As an example, I was recently playing with Pyinfra which is like a pure Python version of Ansible. It turns out that one of the dependencies uses an archaic version of setuptools and the package owner had inserted some _very_ hacky code that ended up breaking on two of my systems. Now I'm relatively experienced with Nix, so it took me a few hours to track down, but it would have been days if not impossible for a beginner.
Nowadays I package brew along with my machines and as soon as something smells funky in Nix I just manage it with brew. Much more peaceful.
Nix Pills are probably the best way to get a deep understanding of Nix and some underpinnings of nixpkgs. I read the pills when I started using Nix in 2018 and never had much difficulty understanding the language or most of nixpkgs.
The biggest thing I've hit is linking issues with Rust -sys crates (ie. C/C++ libraries wrapped). There's some very strange behavior if you include gcc and clang (for example) into the same environment.
My biggest issue with Nix tbh is it adds an annoying step to every random repo I want to clone and build.
I've actually gone the other way - not everything is meant to be run. If it's not in the nix repos, I'll try the fhs, and if that doesn't work - well I probably don't care enough to beg it to run. For me the fact that my base installation can never break is not negotiable.
I definitely didn't learn much of nix(os|pkgs). I never bothered learning about flakes. I just have a configuration.nix and a user config.nix, and a "fhs" default.nix and that's it.
I've recently developed tinnitus within the last few months, so I'm still early in my researching. However, I've found a lot of people that discount this approach and swear it only makes things worse. That's why I've been hesitant to try it.
Do you think a lot of it has to do with having the right mindset?
It honestly may depend on how bad it is and how you react to it. For me, it was causing almost a constant panic-level reaction for weeks. I couldn’t sleep without heavy drugs, and I would wake up sweating and on edge. Just non-stop. I took a fair bit of time off work because of how hard it was to focus. So suffice to say I was willing to try anything.. and the meditation aspect was necessary for me beyond just reducing tinnitus. But I can’t see how it would make things worse, at least not in a permanent way.
I haven't used this technique myself but I can ignore it most of the time, and I think that's an important place to get to. For me, I feel that a big part of it is simply acceptance. If I'd get worked up over it every time I'm noticing it, I think it would be a lot harder to ignore over time. It sucks but this way it sucks a lot less.
It's a funny thing - like a bear in the woods type thing. Sometimes, when its existence gets called to my attention, like when I started reading this story and the comments just now, I suddenly realize how loud it is - but also how I've gone about my whole day without any problems, despite it having been there all the time. Not sure if that makes sense, but that's my experience and it's - fine, really.
Not saying that you shouldn't try other things, and I also don't really know how to get there beyond going easy on yourself. I'm just saying that to me being able to ignore it makes a huge difference in my life quality and so I think it's very worth pursuing. Good luck!
I've had the opposite experience. If I give it that much context it starts to hallucinate parts of the application that it very much has access to look up. This only starts happening at large context windows.
Depends on what you're doing. Too much context and code generation gets sloppy, but it does a decent job attending to the large context to answer questions, analyze control flow, investigate bugs, review style consistency and guideline violations, etc.