What I like about Nix is that this kind of functionality can be integrated into the Nixpkgs package set, as a function over packages.
It's just as easy as writing a machine image or an virtual machine network test, because Nixpkgs has functions you can use for those as well.
This approach is already optimal for up to around 40 or 120 packages, depending on whether you want to support old Docker versions.
"Where before you wouldn’t bother trying to have your application and database images share layers, with Nix the layer sharing is completely automatic."
And can it interact nicely with the "native" environment? I.e. build MSVC projects or ".exe" apps in general that can be used outside of Nix or WSL? I am not a Windows dev but I am very curious, it would be nice to move some cross-platform projects I work on to Nix completely for dev environment...
Re "revert to a last known good working system state": some distributions provides this capability. For example, in NixOS, your system is similar to a git repository in the sense that every package is identified by a unique hash. You can choose to boot any version of your system configuration until you decide to have it garbage collected.
If you're not interested in the "declarative, reliable, DevOps-friendly"[1] approach of Nix, you may 'emulate' this behavior a bit with the bulkier approach of snapshotting.
If you're into LISPs and FOSS-only systems, you may prefer Guix instead of Nix.
There are great tools for that in both Scala and Haskell.
In Scala you can use var, which is easy.
In Haskell you can write your algorithm using ST and then use it as a pure function by means of runST. The type system guarantees that all such state is local to the invocation.
Well they put in an effort of 1400 man years for just the software. They even built an interpreter, because (flight/trajectory) requirements were changing all the time.
Also: "The highest level of testing was performed with a high fidelity digital simulation of the computer, spacecraft hardware, and mission environment."
Type class instance parameters must be explicit in Scala, whereas Haskell can usually infer them. That might make a free monad approach more interesting in Scala.
However, if you really want to introduce this complexity in Scala, you will probably first write some nice high-level code, then discover that it causes a stack overflow, then have to learn about the TailRec monad, figure out how to stack your (free-like) monad on top of it, therefore learn monad transformers, which you probably wanted to avoid by using a free-like monad. A library may solve part of the problem for you, but you will have to be aware of your own stack usage all the time. And when it works you should tune your JVM garbage collector for many (many) short-lived objects.
I would either keep it simple in Scala or choose a language that supports this kind of abstraction in a less painful way.
In Scala, the implicit arguments are implicit, yes, but the parameter is not. You will have to declare the implicit parameter, even if you omit a type signature.
I think I forgot to mention the lack of type class coherence. That's also something you should be aware of when you start using type classes.
Domen Kožar and I (Robert Hensing) are working on a brand new Continuous Integration service for Nix users.
Some distinguishing features:
* First class integration with Nix
* Host build agents where you want
* Free plan for open source
We would love to hear your thoughts!