A year ago I was celebrating 15 years in the .NET ecosystem and 30 years as a Windows user. Fast forward to today, I am using Linux, Neovim, Python, Rust, and mostly live in the terminal.

I’m a solo developer, building a greenfield project, so I could have chosen any technology. Since I’m most experienced in Windows with C#, that would have been the more natural choice. Here’s my experience of why I decided to make different choices and whether it was the right call in hindsight.

Why make the change

I’ll start with why I didn’t choose to keep using C#.

As I was planning to create a SaaS web app with microservice architecture, I could have used pretty much any language. I knew TypeScript and C# pretty well, but when I started I thought I was going to do a lot of work building AI agents. LangChain was the most mainstream option at the time for building custom agents, and Python had the best library for it. So that’s what I chose, even though I had zero Python knowledge.

Consider what was the state of software development a year back. The Claude Code moment hadn’t come yet. We still opened Visual Studio Code or Cursor and used auto-complete with AI. But even back then, it was clear enough that language syntax no longer matters. It was more important which language the LLM models knew best and where the AI libraries lived. That comes down to a popularity contest and the two clear winners are JavaScript/TypeScript and Python.

Moving forward to today, I think the frontier models can handle the ~10 most popular languages as well as it gets. I’m doing a lot of Rust development, and I can’t say I feel lesser capabilities from the agents than for TypeScript or Python.

I don’t regret choosing Python by the way. It’s a beautiful language, with a huge ecosystem for AI and algorithms work. It’s concise, which is important for tokens. Not the most performant but it’s not a big deal if the app spends most of its time querying a database or an LLM provider.

A bit further along I had to change one of my services from Python to Rust for performance reasons and actually got 200x improvement in a specific workload. That particular service was doing a lot of regex matching and as it happens Python is quite slow and Rust is quite fast for that.

Changing from Windows to Linux was not planned but came out of necessity. As I was ramping up my agent usage, I was able to run more terminal sessions and more instances of my app in parallel. The memory usage along with the overhead of the Windows Subsystem for Linux (WSL) was bringing everything to a crawl. I figured the only way to get this workload working is with Linux and decided to make the leap . I was right, by the way.

From the author I also build Obics Obics is a telemetry optimization tool to remove observability spend and noise. It finds redundancies in logs, metrics, and traces, and opens pull requests to fix them at the source. Take a look → 40–60% Lower observability costs Finance gets the savings. Without shutting down observability or losing visibility. 20–30% Faster MTTR DevOps and SRE get clean dashboards and alerts that fire on real issues. Zero Cleanup overhead Developers stay focused on product. No more being pulled into telemetry cleanup.

Unanticipated advantages

As it turned out, changing to Linux brought a lot of benefits I didn’t consider.

  1. In the age of terminals, an OS where everything can be controlled with the command-line means a CLI agent can do most anything on its own. Setting up stuff and figuring out problems becomes as difficult as writing a prompt. This is a huge deal given that so much time used to be wasted on environmentconfiguration and syntax problems. Just the other day I wrote a prompt along the lines of “Create a helm chart pack, then set up minikube locally, then deploy the pack to the local minikube, then get my end-to-end tests working on it”. And I swear to programming god, it just worked.

  2. Linux is, unsurprisingly, much faster in most anything. Service startup times, docker build, tests, it’s all incomparably quicker and as a result more joyful to work with.

  3. Developing on Windows and deploying on Linux machines leads to strange corners. And while there are ways to test on Linux or even run Linux locally on Windows with WSL, it all adds extra complexity that you can avoid. I guess that’s one of the reasons Macs are so popular among developers.

  4. I finally achieved my life long dream of working only with the keyboard. Something I couldn’t do in the world of .NET, Visual Studio, and Windows. This was only possible because of development with CLI agents, a terminal-first OS, using Neovim, and the Chrome extension ‘Vimium’.

What I miss

On the C# and .NET side, I can’t say I miss anything specific about the technology. I do miss writing code myself and the satisfaction of the moment when I get it working. Telling Claude Code what to do is just not the same. It’s like playing a game on an “Easy” setting. It’s fun at first to kick everyone’s butt, but when there’s no challenge, it gets boring fast.

But there’s a different satisfaction in working with coding agents. Like continuosly changing the workflow to get the agent to be more effective and watching it improve.

In terms of switching an operating system, it was a big change, no two ways about it. In a matter of 6 months I changed pretty much all the tools that I’ve been using for years. It took time getting used to and regrowing that muscle memory, but by and large the tools have been better. At least for someone into TUI apps.

I do miss some of the tools I had on Windows. It might be the clipboard management, some shortcut, or the ‘Everything’ app for file search. On the other hand, other tools I found work much better on Linux. I changed my email client to a highly customized ‘aerc’ and I built a TUI for Jira , which is also very cool. Not something I recommend trying on Windows.

Final thoughts

While I had a good run with .NET and Windows, I don’t see myself going back to either any time soon.

C#/.NET are great technologies but they lost the very important test of popularity. If you want the best choice in libraries, the fullest ecosystem, and the languages the LLM is best at, those would be JavaScript / TypeScript and Python. A few other languages are also a great choice: Rust has the best performance of any memory-safe compiled language. Go also has great performance but a much nicer syntax. Kotlin and Swift have a monopoly in their respective mobile operating systems, so they’re not going anywhere any time soon.

Other languages are not as interesting at this point. Besides C#, I’m also including Java, C, C++, and Scala in this category. Not to say that tomorrow or in a year you won’t find a job as a Java developer. There are existing projects that will need new features and maintenance for decades. Just look at Cobol. There’s just no reason to start new projects using them. In all honesty, this trend has been going for years before LLMs. But coding agents added the last nail in the coffin, in a manner of speaking.

The bigger win was moving from Windows to Linux. The performance benefits alone are staggering. My service startup time changed from a long minute to ~5 seconds. Memory overhead is minimal in comparison (no WSL, no Windows Defender, no heavy OS). But the ability to configure everything with a coding agent using the command line is possibly an even bigger win.

Comments

Loading comments…