Congrats to Daniel and the team! Excited to see what’s next after this.
When you think about bringing it to production (eg getting dev teams to migrate to it), Nix goes from a genuinely interesting idea to an "oh, that's cute" experimental toy because no one is going to spend hours learning Nix's weird DSL. It's simply not approachable in its base form.
I spent hours converting my devboxes to NixOS and managing my dev environments with home-manager and I still don't have a clue how any of it works. Errors are opaque and annoying to debug. Dev environments constantly break and change in ways that belay the "reproducible" nature of Nix. If someone actively interested in Nix can't easily grasp it, how does anyone expect it to catch on in the real world?
The issue is essentially that configuration options all get merged into a global namespace, but there are no facilities to track where they came from. So when configuration mismatches of certain kinds occur, you get an error in some library code that's trying to merge or coerce two incompatible values, and nothing pointing you to the two places where the conflicting values are originally set.
(This kind of error, the most common mostly-useless error message, is typically easily debugged by searching for the relevant options in your configuration and in the source code of that collection of modules. But that is still backwards and a chore, and deserves a real solution.)
Anyway, the package definitions and builds in Nixpkgs don't use any such module system in any way. So this tool is not wrapping the functionality that is associated with opaque error messages. :)
(Also Nix and Nix-flakes are two different things, like Javascript and React.)
"Nix" isn't really a thing, no more than "Linux" is. It's a collection of tools and languages and frameworks people use to solve various very different problems.
Here's an opposite opinion:
> My hot take is that Nix actually has great syntax
> In particular, the way Nix handles record syntax is exemplary and more languages should copy what Nix does in this regard
And even more related to this discussion:
> A lot of the times, when people say they hate "Nix's syntax", what they more likely mean is that they hate the domain-specific languages of the Nixpkgs overlay system and/or the NixOS module system
https://mobile.twitter.com/GabriellaG439/status/156300116656...
Doesn't devbox depend on Docker, though? I figure any performance losses from Docker would happen with this too.
I got that from the README btw, no guarantees :)
When writing javascript there's often a desire to have "isomorphic" or "universal" applications. Write the code once and run it in _either_ the client or the _server_.
Devbox is taking a similar approach to the development environment: declare it once, run it locally as a shell, and when you're ready, turn it into a container without having to re-declare it. It's only the latter functionality that has a Docker dependency.
What changed?
They are definitely faster and great improvements.
But when I can use Linux through qemu and compile my companies Haskell application in 45s rather than 3m30s...
The choice is obvious to use Linux.
Out of interest, what in your dev process makes using containers so impactful?
Using the dodgy file share volume mounting, maybe for particular file access patterns.
Not in my experience.
If you set up volumes for node_modules or any folders where where dependencies are stored you get the same performance on Mac as anywhere else.
For rust, which I use, I'm able to get better performance on Mac under docker than using rust tools natively. See https://purton.tech/blog/faster-rust-incremental-builds/