I recently found myself in a predicament when starting a greenfield project: choosing the right programming language. With various factors like my future plans, project timeline, team composition, and constraints in mind, I had to make a decision that would best suit our needs.

On one hand, there was Golang—an efficient language with easy deployable binaries, flexibility, and extraordinary developer experience (DX). On the other hand, there was C# paired with .NET. While it boasted a wider talent pool and was more comfortable for my team, it came with drawbacks like a cumbersome deployment process, less enjoyable DX, and slower runtime.

In the end, considering all the constraints, I opted for C# and .NET. Personally, it might not have been my top choice, but it was the most practical given the circumstances.

Throughout the decision-making process, discussions with peers made me realize my strong aversion to .NET. While C# itself isn’t the issue, it’s the .NET framework that poses challenges. Its constraints often force developers into the object-oriented (OO) programming paradigm, which can lead to unnecessary abstraction patterns.

We’re here to solve problems, not just write code. Code is merely a means to an end, not the end itself. Developers shouldn’t be constrained to fit solutions into a particular paradigm when it’s not the best fit. Object-oriented programming was a solution to past complexities, but now it sometimes feels like we’re trying to fit a square peg into a round hole.

In contrast, Golang offers unparalleled freedom. It empowers developers with choices, whether to utilize design patterns or higher-level abstractions. Developers can start with simple solutions and refactor as needed, reducing cognitive load and enabling a focus on problem-solving rather than framework constraints.

I wanted to embrace .NET, but its inherent constraints on developers made it difficult to fully appreciate. Given the choice, I wouldn’t consider it again.