your_fin

This is the most common complaint I see for switching interactive shells to fish/nushell, but it's not a problem in practice. You don't ever uninstall bash, so if you've got a command to paste:

  bash <enter>

  <paste> <enter>

  exit <enter>

Tada!

Can confirm; my team spent the past 9 months upgrading an application JDK 8 -> 17, and there were breaking changes even after we got it compiling + running

> It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it.

Counterpoint: 95% of config-readers are or could be checked in with all the config they ever read.

I have yet to come across a programming language where it is easier to read + parse + type/structure validate a json/whatever file than it is to import a thing. Imports are also /much/ less fragile to e.g. the current working directory. And you get autocomplete! As for checks, you can use unit tests. And types, if you've got them.

I try to frame these guys as "data values" rather than configuration though. People tend to have less funny ideas about making their data 'clean'.

The only time where JSON.parse is actually easier is when you can't use a normal import. This boils down to when users write the data and have practical barriers to checking in to your source code. IME such cases are rare, and most are bad UX.

> Side effects in constructors

Putting such things in configuration files will not save you from people DRYing out the config files indirectly with effectful config processing logic. I recently spent the better part of a month ripping out one such chimera because changing the data model was intractable.

Very roughly, Zig is much closer to Go in terms of philosophy of language design, where as Rust is much closer to Go in terms of the kind of software people write with it.

Go and Zig are both aggressively small and portable languages, and e.g. prefer explicit `defer` where Rust would handle cleanup implicitly. Unlike Zig, Go and Rust are both widely used and mature ~tier-1 languages with a deep bench of native libraries. However, there's a deep gulf between their philosophies. Go values a shallow learning curve and making code easy to write, whereas Rust values expressivness and making it hard to write bad code. This is not to say that you can't write Good Software in Go or make money with Rust code. However, the languages tend to attract distinct groups of programmers, and there's a reason flamewars crop up between their proponents with unusual regularity.

Zig is notable for targeting C's niches of having lots of structural flexibility in memory management, being good at calling C code, and building C programs. C is the native language of most truly powerful interfaces (operating systems, graphics, cryptography, databases, other programming languages, device drivers, low-level networking, etc.), and programs primarily concerned with interfacing with such things tend to be better off written in C. Working with C code is in the happy path for Zig, while other mainstream programming languages demand significant specialized expertise or wrapper libraries (1). Wrapper libraries aren't always available, are almost always less useful than the original, and only save you /some/ build headaches. This makes Zig a candidate in many situations where C - and /maybe/ C++ - are the only real competition.

In short:

If your interest is learning new ways to think about writing programs, Rust will give you a more distinct perspective than Zig. Like Go, there will be lots of libraries and guides to help you out.

If your interest is in learning to write a kind of program you couldn't in Go and think "closer to the metal", Zig is likely better suited to task.

(1): This isn't nearly as true for C++, but there's still enough impeadence mismatch between idiomatic C and C++ to invite interfacing bugs and wrapper libraries.

In this context, I think the prime advantage would be that instead of: - Managing/setting Ubuntu/$distro for the host - Installing Docker compose on host - Writing a docker-compose.yaml file to declare your container architecture - (potentially) Writing a systemd service to bring docker-compose up with the host boot

You just: - Mange/setup nixos - Add container architecture definition to nixos config

The containers, being systemd units, would have all the normal systemd log management like the rest of your system, instead of having to dig through docker-compose logs with a different mechanism than "normal" systemd service logs.

You'd also get all the normal benefits of a nixos system: the config file can be placed on a new system to completely reproduce the system state (modulo databases et all), rollbacks are trivial, etc.