Hmm i don’t think you can compare IntelliJ which is a fully featured IDE with refractor functionalities, full text search, debugger and so on to a vim setup with plugins in docker container, just because they both edit text. This what the author did at the end of the write up. It’s like comparing jQuery to NodeJS, yeah they both generally are for JavaScript but serve a different purpose.
vim, gdb, grep, cscope, ...
Just because you are not familiar with his setup doesn't mean it's not at feature parity and more.
Hell, he might even be running intellij in docker if he wishes.
I use vagrant + ansible to configure my development environment. In the Vagrantfile I specify also the mount of the workspace containing my project. I then edit the code using vscode installed on the host (or vim from inside the box).
So you just shifted your dependency from Docker to Nix. It might be more fun and an intetesting learning experience but also it's more complicated (or at least it's not that widely used like Docker is)
> It might be more fun and an intetesting learning experience but also it's more complicated I can't imagine anyone using both and thinking Nix is more complicated that Docker. And it's not close. > at least it's not that widely used like Docker is "Which has more users" would not enter the top ten reasons I'd choose between tools like this.
> "Which has more users" would not enter the top ten reasons I'd choose between tools like this.
Why not? A big community means that you don't have to solve problems on your own, because someone else has probably solved the same problem before you.
If anything, it should be the > factor when making these decisions.
Personally I'd prefer going with NixOS to achieve the same result. that way you don't even need a docker installation. As a bonus you can actually install the Nix package manager on osx if you're not into Linux (and this way there is no need for virtualization if you're on a Mac) More info: https://nixos.org/
I love the proposition, but frankly it seems to take too much time to learn even the basics. It would be awesome for someone to build a Docker-like experience on top of Nix, though.
Such is the life of a professional.
If you want to reach the areas where you can really improve your productivity, you're gonna have to take weeks or even months to learn something from the bottom up. There is no way around it, and it's the same in many industries. There is no "30 minutes to get more productive than anyone else" in reality, only hard work, understanding and application of your knowledge in the real world.
I find its easier to setup environments via Nix. Its no longer just a bunch of shell scripts.
What never been clear to me, is how does one pin a specific version in nix? For example, say I want python 3.9.2 exactly?
You need to find the Nixpkgs GitHub commit with that specific version – in some cases it won't necessarily be in the binary cache so you have to compile it yourself because otherwise they'd have an insane amount more binaries to host. You can use Cachix to get your own binary cache (or alternatively just straight up host your own), and check out Niv if you want to make it easier to manage pinned Nixpkgs.
"Choosing a base image can be quite daunting. I’m always a fan of Alpine Linux for my application containers, so that’s what I chose." Just be aware that means the musl libc, which is often fine, but not always. Software that expects glibc can crash or have unpredictable behavior. The JVM is a good example, unless you get a JVM that was originally built against musl. And sometimes also issues with busybox, where it d…
Case in point: "Using Alpine can make Python Docker builds 50× slower", https://pythonspeed.com/articles/alpine-docker-python/
That article should be titled, “Most Python packages do not upload an Alpine-compatible wheel to PyPI.”
If you know where to find Alpine-compatible wheels, or host your own, Alpine has no build-speed penalty.
"Choosing a base image can be quite daunting. I’m always a fan of Alpine Linux for my application containers, so that’s what I chose." Just be aware that means the musl libc, which is often fine, but not always. Software that expects glibc can crash or have unpredictable behavior. The JVM is a good example, unless you get a JVM that was originally built against musl. And sometimes also issues with busybox, where it d…
Case in point: "Using Alpine can make Python Docker builds 50× slower", https://pythonspeed.com/articles/alpine-docker-python/
I've used alpine images for python in production and not run into any of these issues. The key is to know how to use multistage builds to cache layers.
I love the proposition, but frankly it seems to take too much time to learn even the basics. It would be awesome for someone to build a Docker-like experience on top of Nix, though.
Such is the life of a professional. If you want to reach the areas where you can really improve your productivity, you're gonna have to take weeks or even months to learn something from the bottom up. There is no way around it, and it's the same in many industries. There is no "30 minutes to get more productive than anyone else" in reality, only hard work, understanding and application of your knowledge in the real w…
I’ve been working with Nix for years and I still find it to be disappointing. I don’t like Docker and I really love the Nix concept, but the execution seems poor. As an example, I spent half of a Saturday unsuccessfully working with people on the Nix Discord to get VS Code configured with some Rust plugins on MacOS. Similarly, if you need to write your own package, it might be easy or it might be a bottomless rabbit hole tar pit in which you have to package the entire dependency tree including a bunch of obscure C libraries with no build docs. More often than not it seems to be the latter. Further still, nixpkgs is horribly documented and dynamically typed and poorly organized, so every time you’re looking at a definition for a certain package and want to know what “shape” its dependencies have, you have to grep around for another package that uses it, then try to work out what that package is passing in as the dependency; however, if the dependency object is returned from another function defined in some other file you’ll just have to rinse and repeat until you come across the original definition. This is well below the bar for “professional work”. Problems like these arise every single time I try to work with Nix, and it becomes an enormous time sink. Docker is pretty shit, but there’s a pretty clear upper bound to the time I’ll spend struggling with it. Not so with Nix.
So you just shifted your dependency from Docker to Nix. It might be more fun and an intetesting learning experience but also it's more complicated (or at least it's not that widely used like Docker is)
> It might be more fun and an intetesting learning experience but also it's more complicated I can't imagine anyone using both and thinking Nix is more complicated that Docker. And it's not close. > at least it's not that widely used like Docker is "Which has more users" would not enter the top ten reasons I'd choose between tools like this.
It means the ecosystem for Docker is more robust than for a Nix, which is patently true (see my comment here: https://news.ycombinator.com/item?id=26689378). I want to like Nix (and indeed I use it for some things), but it’s wildly immature, and maturity is a fine reason to choose one tool over another.
Also “imagine thinking...” is just vapid snark. If you must snark, at least make it substantial.