How I wish Bazel had nix develop (nixcon2025)

Nix's package composition model makes developer environments a natural extension of its core abstractions. A simple shell.nix declaration combined with nix develop provides native tooling access and IDE integration that other build systems struggle to achieve without significant engineering investment. At LinkedIn, I experienced this contrast firsthand while migrating Go repositories to Bazel. I spent six months reverse-engineering Bazel's sandbox internals, writing custom rules to extract SDK paths, generate direnv configurations, and create LSP settings files. This enabled developers to use native Go commands via shell and IDE within Bazel workspaces, which proved crucial for broader adoption (Bazelcon 2024 talk on this topic). In this talk, I'll contrast months of custom engineering against Nix's declarative approach - just a few lines of config that solve the same problem in a manner that's harmonious with the build system. about this event: https://talks.nixcon.org/nixcon-2025/talk/HMKXYP/