Exactly this. One of the first things I tell people struggling with nix is that nix is simple and almost all of the complexity lives in nixpkgs. Knowing where to look for help (is this a nix, flakes, NixOS, or nixpkgs thing?) is one of the hardest problems for beginners.
Nixpkgs specifically needs to be entirely rethought. It has become too large and complex to manage both technically and politically with the number of contributors. Separating out the lib, stdenv/tooling, and package definitions would be a good start.
My personal experience (model y lr) is 4 hour trips are the sweet spot and anything over 6 hours becomes a drag. I can reliably go over 200 miles @ 80mph without charging but after the first charge you have to stop every 100 miles or less. When we do long cross country trips (8+ hours per day) we take the gas car.
I just got back from a road trip in France and the UK and it's funny how much of the reddit-tier discourse is correct yet simultaneously so wrong. There are plenty of rural towns where everyone owns cars. There are highways, strip malls, large shopping centers with massive parking lots, and populated areas with bus service at best. The difference is the scale and the US lands embarrassingly far on one side of it. Even in the smallest rural towns in France we visited, we could hop on regional rail to the nearest large metro area.
Thanks Graham! Glad to see some attempts at improving the dx of sharing expressions with flakes instead of just derivations. I've seen libraries and tools handle this in a ton of different ways. Do you think there will ever be a standardization of the 'lib' output?
My path was vm -> containers -> nix. With nix flakes and the direnv extension in vscode you can get a clean per-project dev environment with zero docker overhead and without dev tools cluttering up your global environment and causing issues.
I like them for defining a small number of env vars for my app that only get injected at run time. I don't like them when other random tools that aren't my app use them. Docker's insistence on automatically using the .env in your home directory is absurd.
I agree that 'real' verification was useful, but on the other hand removing it had the nice side-effect of 'breaking the spell' of twitter's imagined importance. People take it way less seriously now which I think is positive.
Wow, never seen tome before but I built almost the exact same thing at my current company with the only difference being all the sub-commands run in a nix environment. Being able to share bash scripts in our monorepo by just creating a file at ./scripts/bash/foo.bash and calling it with 'my-cli foo' has been awesome. You can also set up runners so ./scripts/js and ./scripts/python works as you would think. Having everything inside of a nix env means all the tools are there and work across everyone's machines.
I don't have a solution for managing services though and that has been the one pain point after moving away from containerized dev envs. The cross platform network and service management you get with docker is pretty ideal. devenv.sh is on to something with their 'services' feature but it doesn't quiet fit the bill for us yet.
I'm not making a value judgement on rendering strategies, spa, etc. I'm arguing that for most js frameworks, building a full stack app with your own database, auth, etc without third party services is not the happy path. These are table stakes in php, ruby, and python. There are exceptions like remix. I'm just deriding a general trend.
> Vercel and Netlify (among others) try and avoid the basic necessity of databases and other backend complexities as if a front-end developer can exist in some shining, pretty land free of that yucky backend stuff.
They are creating the disease and selling you the cure. You see less monoliths in the node community because it's the only ecosystem where the attempting to build a monolith takes you off of the happy path. Most tools and frameworks not-so gently nudge you in the SPA + back-end-as-a-service direction and make the simple thing hard.
Do those allow multiple versions of the same dependency? With npm and cargo (as opposed to composer, etc.) you are never forced to resolve those types of conflicts so you can just keep installing dependencies forever without ever having to trim the tree.
Oh man I've needed this for a while to the point where I was about to build it my self so thanks! It would be great though if it also listed the tagged nixpkgs version in addition to the hash if applicable.
I would be interested to know what percent of victims were busted in by a SWAT team vs recieved a knock on the door. Not trying to minimize the issue as I would prefer if that number was zero, but I am curious of the scale.
That repo is great. It really helped me get from zero to ... where ever I am now (non-zero I guess, I'm still early in my rust journey.) I do wish there was a 'completed' branch I could look at for reference though. Closest I found was this: https://docs.rs/modular-bitfield/latest/modular_bitfield/
Nixpkgs specifically needs to be entirely rethought. It has become too large and complex to manage both technically and politically with the number of contributors. Separating out the lib, stdenv/tooling, and package definitions would be a good start.