Why LSPs AND Package Managers Are Bad

Odin language creator Ginger Bill argues that both language server protocol (LSP) tooling and package managers can quietly harm developer habits—slowing learning, encouraging dependency sprawl, and masking the real costs of complexity. His core claim on LSPs is personal but pointed: heavy autocomplete and “IntelliSense-like” behavior can reduce the need to read code and documentation, making developers less attentive to the actual structure and idioms of a codebase. He’s not anti-LSP in principle; he cites an unofficial Odin language server (“OS” by Daniel Gavin) as a solid option. Still, he says productivity rose when he stopped relying on richer editor intelligence, keeping only basic completion (like Sublime Text’s rudimentary buffer completion) plus go-to-definition.

That stance extends beyond autocomplete. Ginger Bill treats inline documentation and hover tooltips as part of the same convenience umbrella—useful for some workflows, but not essential for building understanding. He also contrasts this with how he works across large screens: documentation in a separate pane is manageable, and he often finds that knowing parameter types and basic signatures is enough without constant context switching. He adds that he doesn’t use LSP-style tooling even for C++ and finds it “really slow,” reinforcing the idea that tool latency and cognitive friction can matter as much as feature richness.

The conversation then turns to package managers, where the critique becomes more systemic. Ginger Bill’s “spicy take” is that package managers make it easier to fall into dependency hell by automating the acquisition of third-party code—raising compile-time, complexity, bug surface area, and security risk. He argues that when dependencies are easy to download, developers stop thinking about what they’re pulling in, version conflicts, and licensing landmines (including the risk of accidentally bringing in GPL code that can break commercial distribution). He also challenges the common assumption that package managers exist because hand-rolling dependencies is too hard; instead, he says teams should understand and control what they depend on, especially for shipped products.

In Odin’s ecosystem, the alternative is “batteries included” plus vendoring. Ginger Bill describes Odin’s standard library split into Base, Core, and Vendor collections, with vendor code shipped alongside the compiler distribution. Vendoring, he says, avoids the “magical” updating behavior of package managers: teams can keep a known-good copy, patch it directly when needed, and rely on the project’s quality bar. He also argues that Odin’s module model—where packages can be directories of files—reduces the “diamond import problem” that arises when file-level modules force extra wrapper files to avoid cyclic dependencies. In his view, using the filesystem hierarchy as the package boundary is a pragmatic way to scale organization without inventing new abstractions.

The discussion closes with Odin design inspirations and tradeoffs: swizzling/shuffling for vectors (mapped to hardware instructions), pragmatic language features like embedding via “using” on struct fields, and a willingness to borrow ideas from languages such as Swift, Go, Plan 9, Jonathan Blow’s work, and Dart. Across it all, the throughline is restraint: make the language help with hardware-aligned productivity, but avoid tooling and dependency mechanisms that reduce understanding or inflate complexity beyond what teams can reason about.