A Deep Dive into Modern Development Environment Tools

In today’s fast-paced development world, having reliable tools to manage development environments is crucial. Two prominent solutions that have gained significant traction are mise (formerly rtx) and nix-shell . Whilst nix is a complex project in its own right we are just going to be exploring the nix-shell elements, steering clear of flakes and nixos for now. While both aim to solve the challenge of reproducible development environments, they take fundamentally different approaches. This article explores their philosophies, capabilities, and practical applications to help you understand what the hell is going on.

The Problem These Tools Solve

Before diving into comparisons, let’s understand the core problem: development environment consistency. Developers frequently encounter issues like:

Works on my machine bro

The Ugly (A Common Scenario)

A developer named Alex completes a new feature and pushes it to the shared repository. When the code reaches the testing environment, it breaks immediately. The QA engineer reports the bug, and Alex responds with the infamous phrase: “That’s strange, it works on my machine!” Upon investigation, it turns out Alex’s local development environment has:

• A different version of a dependency
• A different version of node/python/etc
• Custom environment variables
• Different operating system configuration settings

Dependency hell

Transitive dependencies are particularly challenging because they’re often hidden from view. They occur when your direct dependencies themselves depend on other libraries, creating a complex dependency tree.

Your application depends on libraries A (v1.0) and B (v2.0).

• Library A depends on Library C (v1.5)
• Library B depends on Library C (v2.2)

This creates a conflict for Library C, even though you never directly specified it in your project. Your dependency tree looks like:

Your App
├── Library A (v1.0)
│   └── Library C (v1.5)
└── Library B (v2.0)
    └── Library C (v2.2) ← CONFLICT!

These conflicts can cascade through multiple levels of dependencies, creating intricate puzzles where solving one conflict creates others. As projects grow, transitive dependency conflicts become increasingly common and difficult to resolve.

Complex setup processes for new team members

New developer Elena joins the team excited to contribute. Her manager tells her to “just run make setup to get started.” She runs the command and watches as cryptic error messages fill her terminal:

/bin/sh: 1: mongodb3.2-tools: not found
ERROR: Failed to locate libpq-dev dependencies
FATAL: Cannot find Python 3.7.2 with specific patch level
WARNING: Legacy Node version detected, attempting compatibility mode...

After three days of troubleshooting, Elena still hasn’t written a single line of code. When she asks her colleagues for help, she hears: “Oh yeah, the setup process is tricky. You need to follow these undocumented steps first…”

System pollution

# Installed globally 18 months ago
go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.43.0

Over time, Ada customized her global GolangCI-Lint configuration by adding rules to her ~/.golangci.yml file. She gradually enabled more linters, tweaked their settings, and added custom exclusions based on her preferences. These customizations accumulated over many projects, with Ada rarely documenting which specific configuration was required for which project.

Six months later, the team adopted a CI pipeline that used GolangCI-Lint v1.50.0 with a project-specific configuration file. However, Ada continued using her globally installed v1.43.0 with her custom global configuration during local development. When new developer Marco joins the team, he follows the documented setup process:

# As specified in current documentation
go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.50.0

When Marco runs the code quality checks locally, they pass without issues. However, when he pushes his first pull request, the CI pipeline fails with multiple linting errors. Confused, he approaches Ada for help.

“That’s strange,” Ada says. “Let me check your code… I don’t see any linting errors when I run it on my machine.”

Solution

If all these development environment issues sound familiar, you’ve come to the right place. Both mise and nix-shell aim to solve these persistent challenges, but they take fundamentally different approaches to the problem. Let’s discuss mise first.

mise: The Unified Tool Version Manager

Philosophy and Design

mise positions itself as “the unified tool version manager.” Created by Jared Forsyth, it’s designed to be a successor to asdf , functioning as a one-stop solution for managing multiple language runtimes and tools.

mise’s core philosophy is simplicity with power. It focuses on providing an intuitive interface for developers to specify, install, and switch between different versions of programming languages and tools without deep system integration.

Key Features

1. Global Configuration via ${HOME}/.mise.toml

mise uses a declarative approach through a .mise.toml file:

[tools]
node = "18.12.1"
python = "3.11.2"
rust = "1.67.1"

This file specifies exactly which tool versions a project needs, ensuring consistent environments across developers.

2. Plugin System

mise extends functionality through plugins, enabling support for virtually any language or tool. The community maintains plugins for:

• Node.js (just because your language is popular doesn’t make it good), Python (please stop), Ruby (gross!)
• Go, Rust (very niace), zig (neckbeard), Java (what year is it?)
• Database tools (everything is a database when you think about it)
• CLI utilities (don’t say golangci-lint )
• Your own tasks [5]

3. Shims and Runtime Integration

mise works by creating shims that intercept commands and direct them to the appropriate installed version. This approach is less invasive to the system, making it easier to adopt incrementally.

4. Project-Level Overrides

mise allows different projects to use different tool versions, automatically switching when you change directories. This feature prevents conflicts between projects with competing dependencies. To do this you a .mise.toml file per directory/project. Example:

$ cat .mise.toml

[tools]
rust = "latest"

5. Advanced: mise tasks

At their core, mise tasks are a mechanism for defining and executing project-specific commands or tasks. They allow you to define custom commands in your .mise.toml configuration file that can leverage your configured tools and environments.

Think of tasks as a lightweight alternative to task tasks like Make, npm scripts, or even simple shell scripts, but with the advantage of being intimately integrated with your mise-managed tool versions.

Do not over use this. Say to replace a makefile, these tasks exist as an escape hatch for missing plugins or SMALL script tasks. When in doubt keep things simple.

Basic Configuration

Configuring tasks in mise is straightforward. In your project’s .mise.toml file, you define them under the [tasks] section:

[tasks.build]
description = "Build the CLI"
run = "cargo build"

With this configuration, you can run these commands using:

mise run build

The power here is that these commands will automatically run in the context of the tool versions defined in your mise configuration.

nix-shell: The Functional Approach to Environment Management

Philosophy and Design

nix-shell is part of the larger Nix ecosystem, based on the Nix package manager and the Nix functional language. Created by Eelco Dolstra, it takes a fundamentally different approach by treating the entire environment as a functional derivation.

The core philosophy of Nix is pure functional package management. Each package exists in isolation with explicitly defined dependencies, ensuring reproducibility and avoiding side effects.

Key Features

1. Declarative Environment via shell.nix

nix-shell environments are defined in a shell.nix file that specifies not just tool versions but the entire environment:

{ pkgs ? import <nixpkgs> {} }:

pkgs.mkShell {
  buildInputs = with pkgs; [
    nodejs-18_x
    python311
    rustc
    cargo
    postgresql_15
  ];
  
  shellHook = ''
    export DATABASE_URL="postgresql://localhost/mydb"
  '';
}

Running nix-shell automatically sets up the entire environment, including running npm install if needed. We suggest using nix-shell in tandem with direnv example .envrc file:

set -a

use nix
mkdir -p "${TMPDIR}"

2. Complete Environment Isolation

nix-shell creates completely isolated environments where nothing from the host system leaks in unless explicitly allowed. This isolation guarantees true reproducibility.

3. Deterministic Builds

Thanks to the functional approach, Nix ensures that given the same inputs, you’ll always get the same outputs. This feature makes environments completely reproducible across machines.

4. Advanced Composition

nix-shell allows complex environment composition through the Nix language, enabling sophisticated development setups with precise control over dependencies.

Side-by-Side Comparison

Strengths

mise Shines When:

• You work across multiple projects with different language versions
• You need a simple solution that “just works”
• You want to rely on the existing asdf community

nix-shell Excels When:

• You need guaranteed reproducibility
• Your projects have complex dependencies beyond language runtimes
• You’re working on projects that require system library integration
• You value deterministic builds and pure environments

Weaknesses

mise Sucks When:

• You are using arm
• You get stuck using another tool through mise (pyenv, :eyes:)
• You want a specific esoteric compilation flag (safe strings on ocaml for example)
• Your shims don’t get pruned or updated properly
• You create two config files by accident

nix-shell Sucks When:

• You realize that even slightly modifying nix-shell is painful
• You use golang (nix’s golang support suuuuucks! You are required to keep a separate dependency file.) see here
• You read nix’s documentation
• You attempt to debug it
• You use macos
• You expect a large ecosystem to support you

Conclusion

Choosing between mise and nix-shell depends on:

1. Your team’s expertise: mise has a gentler learning curve, while Nix requires more upfront investment.
2. Project complexity: Simple projects may not need Nix’s power, while complex ones benefit from its comprehensive approach.
3. Existing workflow: mise integrates more easily with existing practices, while Nix may require more significant changes.
4. Reproducibility needs: If absolute reproducibility is critical, nix-shell offers stronger guarantees.

The best approach is to start with a clear understanding of your team’s needs and constraints, then choose the tool that aligns best with your specific situation. Whether you prefer mise’s simplicity or nix-shell’s completeness, embracing modern environment management tools will lead a better devx for your company and happier developers.