When the mainstream options don't quite fit
JetBrains built their reputation by creating development tools that developers genuinely wanted to use. They displaced Eclipse for Java developers with IntelliJ IDEA, and they've built a loyal following across multiple language ecosystems. For years, their relationship with .NET was through ReSharper—a Visual Studio plugin that addressed gaps Microsoft hadn't filled.
The ReSharper Foundation
ReSharper improved Visual Studio in meaningful ways. Better refactoring tools, more thorough code analysis, navigation that actually worked across large codebases. For many .NET developers, it became essential—the thing that made Visual Studio feel complete.
But plugins that improve your workflow also highlight gaps in the host product. Eventually, JetBrains decided to build something that didn't depend on Visual Studio at all.
Rider: A Complete Alternative
Rider launched as JetBrains' standalone .NET IDE, built on the same foundation as IntelliJ IDEA. It incorporates ReSharper's analysis engine but runs independently, without Visual Studio as a host.
The result is a capable IDE that doesn't feel like a compromise. The code analysis is thorough, refactoring tools work reliably, and the debugging experience is solid. It's not trying to be Visual Studio—it's an alternative built from different design principles.
Cross-Platform Consistency
Rider's clearest advantage is platform support. It runs on Windows, macOS, and Linux with identical functionality. For developers who work across operating systems, this matters. The same project, same shortcuts, same workflow—regardless of which machine you're using.
This isn't a theoretical benefit. When I'm working on my Windows desktop versus my Mac laptop, Rider provides consistency that Visual Studio can't match.
Interface Design
Rider's interface feels more intentional than Visual Studio's. Where Visual Studio has accumulated features over decades (sometimes showing its age in the UI), Rider's layout is more coherent. Tools are organised logically, and the overall experience feels considered rather than accumulated.
It's still a complex IDE with many panels and options, but the organisation makes navigation more intuitive.
The October 2024 Licensing Change
In October 2024, JetBrains made Rider free for non-commercial use—personal projects, open-source work, and learning. This is full-featured Rider, not a limited edition.
This removes one of the main barriers to trying it seriously. Previously, the subscription cost made it difficult to justify for individual developers who already had access to Visual Studio.
Why I Haven't Fully Switched
Despite Rider's strengths, I haven't made it my primary IDE. The reason is straightforward: switching your main development environment is disruptive. You lose accumulated muscle memory, familiar shortcuts, and intuitive knowledge of where everything lives.
When I have used Rider for actual projects, it's been capable. The experience is professional, not a compromise. But Visual Studio's grip on my workflow is strong, and the switching cost is real.
The Corporate Context
Most organisations standardise on Visual Studio for .NET development. Suggesting Rider requires convincing people that the benefits outweigh the switching costs and the divergence from team standards. That's a difficult case to make when Visual Studio already meets requirements.
For personal projects where I control the tooling decisions, Rider is worth considering—especially now that it's free for non-commercial use.
Rider's Position
Rider is a competent alternative to Visual Studio that doesn't feel like settling. It's built by people who understand .NET development and have a track record of quality tooling.
In a landscape dominated by Microsoft tools, having a quality alternative from a different company has value. Rider doesn't need to be revolutionary—being reliably good is enough.
Neovim: Terminal-Based Development
Neovim represents something fundamentally different from the IDEs we've discussed. It's not trying to be user-friendly in the conventional sense. It assumes you'll invest time learning it, then rewards that investment with efficiency.
Neovim is a modern fork of Vim, the terminal editor that's been a developer staple since 1991. It keeps Vim's modal editing philosophy—where keys execute commands rather than inserting text—while adding contemporary features like built-in LSP support, Lua-based configuration, and better extensibility.
Modal Editing
The core concept that distinguishes Vim and Neovim: modes. In normal mode, keys execute commands rather than inserting text. dw deletes a word. ci( changes text inside parentheses. $ moves to line end.
Commands combine logically. d3w deletes three words. ci" changes text inside quotes. The grammar is consistent: action + motion or action + text object.
The idea is that once you internalise these patterns, editing becomes more direct. Your hands stay on the home row. You stop reaching for the mouse.
The Learning Investment
The learning curve is genuinely steep. For the first few weeks, basic tasks take longer than they would in any GUI editor. You'll make mistakes—inserting text when you meant to navigate, searching when you meant to move.
This is the barrier that stops most people. The question is whether the eventual efficiency justifies the upfront investment.
Where It Fits My Workflow
For terminal-centric work, Neovim makes sense. When I'm already in a terminal running build commands, checking logs, or managing containers, opening Neovim is seamless. No context switch, no waiting for a GUI to initialise.
For smaller projects, scripts, and configuration files, the speed is noticeable. Neovim opens instantly. Edits happen quickly. The overhead is minimal.
For my personal hobby projects, Neovim has become my primary choice. It integrates well with terminal-based workflows—tmux for session management, command-line tools for building and testing. Everything stays in the same environment.
Modern Neovim
The Neovim of 2026 is substantially different from Vim of a decade ago. Built-in LSP support provides IDE-like features: autocompletion, go-to-definition, inline diagnostics. Telescope offers fuzzy finding comparable to VS Code. Tree-sitter enables better syntax understanding.
The plugin ecosystem has matured. File trees, Git integration, debugging support—the functionality gap with traditional IDEs has narrowed significantly.
Configuration is now in Lua rather than Vimscript, making customisation more approachable. Distributions like LazyVim provide sensible defaults without requiring deep configuration knowledge.
Practical Limitations
For substantial .NET projects with complex solutions, I still prefer Visual Studio or VS Code. The debugging experience is more polished, tooling integration is smoother, and I don't need to think about the editor—it just works.
Neovim occupies a specific niche in my workflow: terminal-native editing where I want speed and minimal overhead. It's not trying to replace my IDE for everything, and that's appropriate.
The Underlying Philosophy
Vim and Neovim embody a different philosophy from modern software design. They prioritise efficiency after learning over immediate usability. They assume you'll read documentation and invest time upfront.
This appeals to some developers and frustrates others. Whether it fits you depends on your temperament, your workflow, and how much time you're willing to invest.
Should You Try It?
If you're curious about terminal-based development, work frequently in SSH sessions, or want to understand text editing at a deeper level, Neovim is worth exploring. Start with a distribution like LazyVim to avoid configuration complexity. Use it for a month on side projects before judging.
But don't feel obligated. Using Neovim doesn't make you a better developer. Using VS Code doesn't make you a worse one. Tools serve purposes—use what makes you productive.
The practical benefit that transfers: Vim keybindings are widely supported. Most editors offer Vim modes. Many terminal tools use Vim-style navigation. Learning the motion model pays dividends beyond Neovim itself.
Next: Part 4 - What I actually use day-to-day, and how to think about your own choices