[rounce]

> Need to work inside a container because it's 2025 and we don't need to clutter our local machine with 100s of dependencies and env managers...

“Can I tell you about our lord and saviour Nix?”

Kidding, but seriously though I’ve found having to work in a container to be a bit clumsy, even with good tooling around it. As you said it’s 2025, and there are other ways to have reproducible toolchains that don’t pollute the rest of your system environment Nix or otherwise.

[traceroute66]

> “Can I tell you about our lord and saviour Nix?”

The "just use Nix" people are just like the "write it in Rust" brigade.

And the things both groups promote share exactly the same problem ...

A stupidly enormous learning curve.

That's why your average person prefers to just the job done in a container vs Nix, or in Go vs Rust.

I'm sure Nix is awesome, just like I'm sure Rust is awesome. But honestly, I've got enough going on in my brain at $work and $home without having to wrangle some obscure config syntax (Nix) or obscure low-level language complexities (e.g. Rust's infamous borrow-checker).

Every time I go back and look at Rust or Nix my brain is just like .... no, thanks.

[eptcyka]

Rust forces you to consider things upfront, or to put it another way, a C developer does what the borrow checker does manually. Sometimes, they do it after asan/ubsan/tsan has reported the issue. Sometimes it's after a segfault. Usually it's after the user hits the bug already.

Nix similarly forced issues to be reasoned with upfront.

[jeremyjh]

Yes and most people are happier with a garbage collector than using C, C++ or Rust. There are domains or projects where you have to use one of those languages, but Rust is being used and promoted far outside those niches.

[tempaccount420]

So you rather stay comfortable doing what you were always doing, which is fine but programming is everything but that...

[miroljub]

Complexity for the sake of complexity is not a goal everyone should be striving for.

[traceroute66]

> Complexity for the sake of complexity is not a goal everyone should be striving for.

THIS !

Go's well maintained stdlib just lets me get on with it.

With Rust meanwhile, I have to decide which of thousands of third-party Rust crates is sufficiently en-vogue and well maintained.

Most of my coding work is backend stuff that calls a lot of HTTP APIs, parses a lot of JSON and does a lot of crypto. All that is ready-to-go "out of the box" with Go stdlib and on top of that is faster to get to production in Go than in Rust.

I don't need or want Rust's complexity. As I said I have enough going on at $work...

[flashgordon]

I always feel like choosing between rust and go is like picking between node (ts/js) and python when it comes to stdlib out-of-the-box-ness!

[ccanassa]

I think LLMs have solved that for Nix. I recently moved my homelab from an Ansible/Debian setup to NixOS. As long as I understand at a high level what Nix is and what problems it solves, I can let the LLM deal with the configuration language.

[rounce]

I didn’t say “just use Nix”, I jokingly made a reference to street evangelists and the similarities they have in their approach with people who are excited about a particular technology. In fact I said “Nix or otherwise” implying there are many options when it comes to reproducible per-project environments.

[verdverm]

joking or not, people are very tired of the evangelists (fanbois?) from these ecosystems, and this culture around them is one reason others stay away. The broader trend is developers are burnt out on tooling churn

[rounce]

(That’s the joke)

[bigyabai]

That's a fine opinion to have. You just have to fight a separate shoggoth of a mutable-root system, which mainstream Linux vendors like Google and Valve have avoided.

It's similar to the Rust situation in that many Rust programmers are simply tired C++ programmers fed-up with using Valgrind and Cmake. Nix is the retirement-home for people who clean up package pollution and just want stability at any cost.

[adastra22]

In the case of AI tools it is for security reasons, not just reproducible toolchains.

[viraptor]

We need more selinux and sandbox-exec in daily dev lives. There's no reason to bring a whole new system along just to restrict some access.

[adastra22]

Docker is just a shim on kernel isolation APIs. It’s not any different, but better packaged.

But irrelevant in this case. I dev on macOS. I’m not aware of any other options.

[viraptor]

sandbox-exec. It's not great, but it's usable. https://igorstechnoclub.com/sandbox-exec/

> It’s not any different

It's very different. With docker on Mac you're running a VM which runs a wrapped up complete system that runs your app.

With selinux/sandbox-exec you run just your app and can skip the extra packaging needed for docker and mounts. (And get the extra performance)

[rendaw]

Does selinux/sandbox-exec work on a Mac? Is this an apples to apples comparison?

[viraptor]

sandbox-exec is a Mac exclusive thing.

[sebmellen]

Wow TIL

[internet_points]

Any references to how you use selinux? I've used bwrap and firejail, but I don't feel confident that I'm not leaving holes open?

[viraptor]

Honestly - no. To use selinux you need to commit to actually learning how it works and experimenting a bit. I don't think there's an easier way than reading both redhat (https://docs.redhat.com/en/documentation/red_hat_enterprise_...) and NSA (https://www.nsa.gov/portals/75/documents/resources/everyone/...) docs.

If you're happy with firejail, make sure you use whitelists only and you'll be 90% there with what's possible to achieve.