Hacker News new | ask | show | jobs
by stefanha 1311 days ago
I avoid "developer environments" because they are different from production environments and that leads to bugs that don't show until the application is in production. "But it worked in development" problems waste a lot of time.

Putting "developer environment" in the name of this tool perpetuates bad practices.

Any tool that constructs environments for applications should be general enough to handle both production and development.

5 comments

Err, playing that card in this context looks a bit disconnected to me.

Does this suggest a bit of unknowns in Nix and Nix OS?

You don’t want to deploy your development tool chain to your production environment, ergo, you want a development environment.
In the JS world it's common to have hot-reloading development servers, whereas the production environment does not do that. And with the rise of TS, transpilation and bundling are also a thing on the backend, not just for shipping web assets. Once the bundle is done, all your production server needs is `index.js` and `node`, not `tsc`, `webpack` or whatever else you're using.
‘Node’ on dev may run differently than node on production depending on version of dependencies , for eg a shared object file it loads.
Yes, of course that could happen. All I'm suggesting is that the optimally productive tradeoff is somewhere in between "develop in a full clone of production cloud" and "works on my machine and nowhere else".
I would totally want to deploy on the prod environment. If the tools have their symbols resolved properly, they should run on any reasonable environment.

The other way around that we build a dev environment that is different from prod just makes no sense.

Why not use Nix in production, then? Hermetic evaluation of all dependencies allows a deterministic dev/prod set of environments.

I, at the very least, completely disagree with you on this specific point as this tool is using Nix.

This is what the last paragraph was intended to convey. The tool should be aimed at setting up any environment, not just development.
Fine, let's just develop on production. Cases solved
Good idea. Let’s go beyond merely testing in prod
Cut cloud cost by half, no more 'it works on my machine ' problem, it just works or it won't.
The word you are looking for is staging environment