Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Will Nix Overtake Docker?

blog.replit.com

Post reply on HN
Print view View original

201–210 of 259 posts

Re: Will Nix Overtake Docker?

#201

Post by funcDropShadow »

Zababa wrote: post #134
Barrin92 wrote: post #60

Earlier quoted context omitted.

>Build times in Haskell were bad enough this one's very true. Every time I try to build something in Haskell on my laptop it feels like we're moving closer to the heat death of the universe. Is there some good read on how/why Haskell compilation times are so long compared to some other languages?

I can't offer an answer specific to Haskell, but I know that OCaml does some things to make the compilation fast: interface files, no circular dependencies, no forward declarations, not a lot of optimizations. From what I understand, those tradeoffs come from languages designed by Niklaus Wirth, where efficiency of compilation was important. In general, I feel like every language that wasn't made to compile fast like…

Haskell compiles so slow because it needs way more optimizations then Ocaml before it performs good. The primary reason for that is its lazy evaluation semantics. Prior to GHC many researchers believed it to be impossible to execute lazy languages with comparable speed than imperative ones. Haskell and GHC were primarily developed as research tools. I.e. they valued the efficient exploration of new ideas in programming languages and implementations higher than the resulting language and implementation, at least in the beginning. And I would say Haskell was extremely successful considering those priorities.

That does not mean, that the implementation hasn't been moving towards industry-readiness for a long time.

Re: Will Nix Overtake Docker?

#202

Post by KronisLV »

eximius wrote: post #106
amarshall wrote: post #103

Earlier quoted context omitted.

Worth noting in this context of OP, though, is that Nix predates Docker by about a decade.

That is extremely concerning, then, that it is so difficult to use after all that time. I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years".

> That is extremely concerning, then, that it is so difficult to use after all that time.

> I had hopes in the back of my head that "maybe it'll get better/more ergonomic in the next few years".

I feel much the same way about wanting to run something like FreeBSD and having it just work, as opposed to running into weirdness because of the driver situation, with which GNU/Linux seems to be getting better at (even though you sometimes are forced to install proprietary ones for optimal experience, should get better in the next decade).

So, might have to wait for a bunch more years, or just pick something else, like OpenBSD, or just run in a set of constraints for having a really predictable and well supported hardware configuration, which isn't always possible. Alas, my off brand Polish netbook will just have to wait before i can (hopefully) run BSD on it comfortably. Well, short of making the missing pieces of puzzle myself, for which i'd probably also need a decade or so of systems level development experience, as opposed to just web dev and occasionally dabbling in lower level stuff to mediocre success. Of course, by then the netbook itself might not be relevant, so who knows.

I also feel much the same way about GNU/Hurd - a project that is conceptually interesting, but isn't yet quite stable, even though apparently you can get Debian for it: https://www.gnu.org/software/hurd/

Now, i don't have almost any experience with it, apart from reading about it, but some people tried figuring out when it could be released based on the bug reports and how quickly they were being addressed, and the number that they came up with was around 2070 or so.

In summary, there are probably projects out there, for which their age isn't necessarily related to how usable they are, whereas other pieces of software will have never truly achieved that stability in the first place. Not all old software is good (edit: at least not for certain use cases).

Of course, there are exceptions, for example, you can look at Apache2/httpd: it is regarded as old and dated for the most part, however just recently an update was released, which added mod_md. It now lets you get Let's Encrypt certificates without external tools (like Certbot), in some ways setting it ahead of Nginx: https://httpd.apache.org/docs/2.4/mod/mod_md.html Not all old software is always boring.

Same for Docker and any other tools. If developers use tool A for use case X, instead of tool B, then maybe there are some very good reasons for this widespread usage? That's also probably the answer to this debate - regardless of their conceptual/technical benefits, the usability will probably decide which tool will win in the long term.

Re: Will Nix Overtake Docker?

#203

Post by Nullabillity »

throwaway894345 wrote: post #197
Nullabillity wrote: post #181

Earlier quoted context omitted.

You can use Nix as a better docker build, see https://grahamc.com/blog/nix-and-layered-docker-images or https://nixery.dev/ .

The dream is using something like Nix to not only reproducibly build a container image but also all of the infrastructure manifests which reference it. I _think_ this is achievable in Nix if you're willing to deal with all of the pain of actually using Nix; however, this would depend on pushing an image to a container registry as part of the Nix build and I'm pretty sure that violates Nix's idioms/conventions? I've c…

> The dream is using something like Nix to not only reproducibly build a container image but also all of the infrastructure manifests which reference it. I _think_ this is achievable in Nix if you're willing to deal with all of the pain of actually using Nix;

We did that at an old job. Basically, Nix built images + K8s manifests + a script to push the images. Our CI job boiled down to `nix-build && ./result/push-images && kubectl apply -f ./result/manifests -R`. This is similar to how NixOS' nixos-rebuild boils down to `nix-build && ./result/activate`.

Re: Will Nix Overtake Docker?

#204

Post by kwertyoowiyop »

rgoulter wrote: post #47
exdsq wrote: post #29

Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS and used Nix whenever I could to try and pick it up, but it's such a complex beast I felt it slowed everything down. Simple tasks that would take 10 minutes in Docker suddenly became DevOps tickets. I suddenly had to write bindings for tools rather than apt-get…

> There's a blog post that goes around from time to time about how a company have three risk tokens to allocate per project on non-boring technologies. https://mcfunley.com/choose-boring-technology

Strangely, once a team adds one risk, they feel more comfortable adding a second risk. Ditto for the third risk, etc. The psychology is weird.

Re: Will Nix Overtake Docker?

#205

Post by kwertyoowiyop »

Frost1x wrote: post #179
goodpoint wrote: post #169

Earlier quoted context omitted.

It's well documented that Docker and especially docker hub had a terrible impact on security. Once you factor in the efforts required in the long term to mitigate a decade of bundling gigabytes of applications and libraries it's a huge "dev adventure"

More like developer Towers of Babel waiting to collapse on every build attempt. Docker is fine if it's used correctly but it does add a layer of complexity, it doesn't abstract it away.. The way I see it rampantly (ab)used is as a shortcut to get some software up and running by leveraging a public image and passing tech debt for some component of one's system onto the maintainer of the Docker image, then cobbling tog…

“You mean Amazing Architect Andy who just left for Google?” :-(

Re: Will Nix Overtake Docker?

#206

Post by copperx »

carlmr wrote: post #192
eitland wrote: post #122

Earlier quoted context omitted.

> It's just as easy to make a mistake with git today as it was however many years ago; Pro tip from an actual pro : git became significantly easier for me once I decided 1. to just use a good comfortable gui (at least one tui also look good) for anything beyond commit and push. (maybe not everything can be done from your gui of choice but at least you get a good overview of the situation before you dive in with the c…

Which git GUI do you recommend? The one in VSCode I find even more confusing than the CLI. I do agree with you that some workflows are just easier with a GUI, since I used to use TortoiseSVN and it was much nicer for diffing two commits than the CLI is. But I haven't really dug into git GUIs.

Magit is the most recommended one. But it comes with an Emacs dependency.

Re: Will Nix Overtake Docker?

#207

Post by KronisLV »

carlmr wrote: post #192
eitland wrote: post #122

Earlier quoted context omitted.

> It's just as easy to make a mistake with git today as it was however many years ago; Pro tip from an actual pro : git became significantly easier for me once I decided 1. to just use a good comfortable gui (at least one tui also look good) for anything beyond commit and push. (maybe not everything can be done from your gui of choice but at least you get a good overview of the situation before you dive in with the c…

Which git GUI do you recommend? The one in VSCode I find even more confusing than the CLI. I do agree with you that some workflows are just easier with a GUI, since I used to use TortoiseSVN and it was much nicer for diffing two commits than the CLI is. But I haven't really dug into git GUIs.

Here are some recommendations:

SourceTree: https://www.sourcetreeapp.com/

Windows and Mac. Free. Feels sluggish, but is also really dependable, the graph view is lovely and it covers most of the common things that you want to do - also, staging/discarding chunks or even individual lines of code is lovely. Oh, and the Git LFS integration, and creating patches is also really easy. And it gives you the underlying Git commands it uses, in case you care about that.

GitKraken: https://www.gitkraken.com/

Windows, Mac and Linux. May need commercial license. Feels like a step up from SourceTree, but i find that using this for commercial needs is a no go. If that's not an issue, however, it has a good UI, is nice to work with and just generally doesn't have anything i'd object to. IIRC it saved my hide years back by letting me do a ctrl+z for a repo after accidentally forcing to the wrong remote, so that i could fix what i had done (memory might fail me, was years ago), just generally feels intuitive like that.

Git Cola: https://git-cola.github.io/

Windows, Mac and Linux. Free and open source. Perhaps one of the more basic interfaces, but as far as free software goes, it does what it sets out to do, and does it well. I use this on Linux, whenever i want to have that visual feedback about the state of the repo/staging area or just don't feel like using the CLI.

TortoiseGit: https://tortoisegit.org/

Windows only. Free. Recommending this just because you mentioned TortoiseSVN. If you just want a similar workflow, this is perhaps your best option. Honestly, there is definitely some merit to having a nice file system integration, i rather enjoyed that with SVN.

Whatever your IDE has built in: look at your IDE

On any platform that your IDE runs on. Same licensing as your IDE. Some people just shop around for an IDE that they enjoy and then just use whatever VCS workflows that they provide. I'd say that VS Code with some plugins is really nice, though others swear by JetBrains' IDEs, whereas others are fine with even just NetBeans or Eclipse (Java example, you can replace that with Visual Studio or whatever). If you're working within a particular stack/IDE, that's not too bad of an idea.

The CLI: https://git-scm.com/

Windows, Mac and Linux. Free and open source. You'll probably want to know a bit of the CLI anyways, just in case. Personally, i'm still way too used to using a GUI since dealing with branches and change sets just feels like something that's more easy when visual, but the CLI has occasionally helped me out nonetheless.

Actually, here's a useful list of some of the Git GUIs: https://git-scm.com/downloads/guis

For example, did you know that there are some simple GUI tools already built in, git-gui and gitk?

Re: Will Nix Overtake Docker?

#208

Post by xxpor »

xyzzy_plugh wrote: post #38
xxpor wrote: post #20

Earlier quoted context omitted.

Nix supports this quite well. https://nixos.org/manual/nix/stable/#multiple-versions The Nix and container mindset are very similar in that they refer to all of their dependencies, including down to glibc.

Not quite. This is true for dependencies such as libraries but for services it's significantly trickier. Postgres, for example, would require configuring each version to use a distinct space for storage and configuration if you want to run them concurrently. It's still pretty easy with NixOS, but not as simple as you make it seem.

It's one line of override configuration, how is that not trivial?

Edit: Totally granted, figuring out that one line the first time might take 6 hours, but once you know how to do it you're good to go the next time. The documentation could certainly be improved.

Re: Will Nix Overtake Docker?

#209

Post by xxpor »

tyingq wrote: post #73
xxpor wrote: post #20

Earlier quoted context omitted.

Nix supports this quite well. https://nixos.org/manual/nix/stable/#multiple-versions The Nix and container mindset are very similar in that they refer to all of their dependencies, including down to glibc.

Does Nix understand network namespacing? Or would 2 postgres instances clash over tcp listen ports? I get you could configure different ports, or virtual interfaces, but it sounds like either of those would be outside of the nix tooling.

You would have to deal with that yourself. But it's typically just a variable in the service definition, so it's very easy to override.

Re: Will Nix Overtake Docker?

#210

Post by KronisLV »

kwertyoowiyop wrote: post #205
Frost1x wrote: post #179

Earlier quoted context omitted.

More like developer Towers of Babel waiting to collapse on every build attempt. Docker is fine if it's used correctly but it does add a layer of complexity, it doesn't abstract it away.. The way I see it rampantly (ab)used is as a shortcut to get some software up and running by leveraging a public image and passing tech debt for some component of one's system onto the maintainer of the Docker image, then cobbling tog…

“You mean Amazing Architect Andy who just left for Google?” :-(

That's at least partially why we have CV driven development be a thing in the industry. Either you jump on the NoSQL, AI, ML, blockchain, serverless, microservice, container, $FOO bandwagons, or you'll miss out on job opportunities and will have your CV stagnate.

That's not to say that those technologies don't have good use cases in particular circumstances, it's just that you as an IC probably don't have strong incentives to care about where the project will be in 5-10 years when you will have left for another company in 2-3. A lot of accidental complexity is an unavoidable reality when you have people who put their own careers ahead of most other concerns.

Post reply on HN