nrdxp

(started as a response during a private conversation about how using multiple languages could get confusing or overly complex, when discussing how Nix is used as a general purpose configuration language)

So the more I gained experience with Nix, the more I started to personally feel that the main issue was (a lack of) clean boundaries. So I do think there is room for multiple languages, but the key is to be consistant in what they are used for. From that perspective I think there is room for a few different languages. Something like:

• nix as a DSL for packaging (not config)
• some actual programming language for config (because I despise yaml templating)
  • Nickel: still doesn't really have a "killer-app" to demonstrate its value, but on the surface it seems promising
  • Dhall: I actually love that dhall is not turing complete. If its type system wasn't so damn rigid, it would be my preferred choice here, but unfortunately that is not the case
• Cue: it seems like cue is starting to win this batt

nrdxp

Well my approach is a fundamental shift in how we would run a Nix evaluation, based on 10 years of being annoyed at how costly evaluation can be sometimes, and the experience I gained in that time from Nix and software engineering in general.

So far includes two components, a novel Nix module system that actually provides sensible boundaries for Nix code for not much cost (it is actually insanely fast compared to the NixOS module system). This piece makes the Nix code bounded and trvially statically analyzeable. It perpusefully bucks the trend of depending on nixpkgs and being super complex and heavy. The core of it took me two hours to write and I have kept it purposefully small since. Besides performance and predictability, another nice feature is trivial tracing (unlike the monsterous traces produced by the nixos module system). There is still some work to do to integrate it more cleanly with my CLI, and I am almost at that stage.

As for the Rust based cli, there are a few core planned features but right

nrdxp

{
  std,
  nixpkgs,
  ...
}: {
  nomadJobManifests = name: let
    type = std.nomadJobManifests name;
  in
    type
    // {

nrdxp

REPO_DIR="$(git rev-parse --show-toplevel)"
LOCK_FILE="$REPO_DIR/nix/cloud/packages/<ommited>/deps.lock"

cd $REPO_DIR
# We want our lock file to be reproducible so ensure the cache from previous runs is removed
rm -rf .nix

# This is for CI to check if the lockfile has changed
if eval __argCheck__; then
  lock_hash=$(nix hash file "$LOCK_FILE")