moojd

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.

> No one is asking you to live there or not have a vehicle.

Several of the most upvoted comments in this very thread are advocating banning vehicles.

I like that git allows rebase, as long as it is only done in prs or local. Rebase in the sheets, merge in the streets.

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?

Enterprise discord is one of those obviously inevitable things that I can't believe doesn't exist yet

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.

Some execute them as a shell script and others parse them as a newline separated list of key value pairs

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.