2025-09-05 –, Aula
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.
Hi there, I'm Srini. I previously worked at Apple Maps and LinkedIn, primarily in the build systems space. I'm a recent Nix convert (my primary expertise is in Bazel) and I'm looking forward to delving deep into all things nix and being a part of the community!