Forem: ridd

The Backend Language War 2025: Go vs Rust vs Python vs Node.js. Which Should You Learn?

ridd — Mon, 08 Dec 2025 05:27:14 +0000

Every few years, the backend development landscape shifts. New frameworks emerge, old languages fade, and developers are forced to adapt.

In 2025, the same question keeps appearing in forums, Twitter threads, and engineering discussions: which backend language should I learn?

The answer isn't as simple as "pick the most popular one." Each language has its strengths, weaknesses, and ideal use cases. And more importantly, your choice can significantly impact your career and salary.

Let's break it down.

The Four Contenders

We're looking at four languages dominating backend development today: Python, Node.js, Go, and Rust. Each has carved out its own territory, and understanding where they excel will help you make a smarter choice.

Python: The Versatile Veteran

Python has been around since 1991, but its popularity exploded in the last decade thanks to one thing: AI and Machine Learning.

The language shines with its readable syntax and massive ecosystem. TensorFlow, PyTorch, scikit-learn: all the major ML libraries live here. Web frameworks like Django and FastAPI are mature and battle-tested. If you need to prototype quickly or build data pipelines, Python is hard to beat.

But Python has trade-offs. It's slow compared to compiled languages. The Global Interpreter Lock (GIL) limits true parallelism. Memory usage runs high. For CPU-intensive tasks, you'll feel the pain.

Who uses it: Instagram, Spotify, Netflix, and virtually every AI/ML startup.

Salary range (US): $130K - $180K/year

Node.js: JavaScript Everywhere

Node.js brought JavaScript to the server, and that changed everything. One language for frontend and backend means consistency and easier hiring.

The npm ecosystem is massive, with over 2 million packages. Event-driven, non-blocking I/O makes Node.js excellent for real-time apps like chat, gaming, and live updates. If your team already knows JavaScript, the learning curve is minimal.

The downsides? CPU-bound tasks will block your event loop. Single-threaded by default. Performance can't match compiled languages. And while async/await helped, complex codebases can still get messy.

Who uses it: Netflix, LinkedIn, PayPal, Uber.

Salary range (US): $120K - $138K/year

Go: The Cloud-Native Champion

Google created Go in 2009 with a clear goal: simple, fast, and scalable. They nailed it.

Go compiles to native binaries with zero runtime dependencies. Goroutines make concurrency trivially easy. You can handle thousands of concurrent connections without breaking a sweat. The syntax is minimalist, the tooling is excellent, and the learning curve is gentle.

The trade-offs are real though. Go's type system is simpler (generics only arrived in 1.18). Error handling is verbose. And while the garbage collector is highly optimized, it can still cause latency spikes in extreme cases.

Who uses it: Google (Kubernetes, Docker), Uber, Twitch, Dropbox, Cloudflare.

Salary range (US): $135K - $200K/year

Rust: The Performance King

Rust is the youngest language here (2010), but its growth has been phenomenal. It offers something unique: C/C++ level performance with memory safety guarantees.

No garbage collector means predictable performance. The ownership system prevents memory leaks and data races at compile time. Zero-cost abstractions let you write high-level code without sacrificing speed. The compiler is strict but incredibly helpful.

The catch? Rust has the steepest learning curve of all four. Ownership and borrowing concepts take time to internalize. Compile times are longer. The ecosystem is still growing. Initial development speed is slower.

Who uses it: Discord (migrated from Go), Cloudflare, Mozilla, Dropbox, AWS.

Salary range (US): $150K - $210K/year (highest!)

Performance: The Numbers

Let's look at concrete benchmarks from TechEmpower 2025:

Language	Framework	Requests/sec	Relative
Go	Fiber	~338,000	20x
Rust	Actix	~320,000	19x
Node.js	Fastify	~98,000	6x
Python	FastAPI	~45,000	3x
Python	Django	~32,000	2x

For compute-intensive tasks (Fibonacci calculation):

Rust: ~22ms
Go: ~39ms
Python: ~1,330ms

The gap is massive. But remember: raw performance isn't everything.

When to Use What

Here's a practical decision framework:

Choose Python if:
You're building AI/ML applications, need rapid prototyping, or want to leverage a massive ecosystem. Great for startups where speed-to-market beats scalability concerns.

Choose Node.js if:
Your team is strong in JavaScript and you want full-stack consistency. Ideal for real-time apps, I/O-heavy microservices, or when you need access to npm's vast ecosystem.

Choose Go if:
You're building cloud-native applications that need high concurrency without complexity. Perfect for infrastructure tools, CLI apps, DevOps tooling, or when scaling is priority number one.

Choose Rust if:
Performance is critical and every millisecond matters. Best for systems programming, fintech, blockchain, or replacing legacy C/C++ code. Requires an experienced team willing to invest in the learning curve.

The Discord Case Study

One of the most fascinating examples is Discord's migration from Go to Rust.

The problem: Go's garbage collector, despite being highly optimized, caused latency spikes during critical moments. For a service handling millions of concurrent connections, those GC pauses were noticeable.

The solution: Rust's ownership system handles memory at compile time. No GC, no pauses. The result was more predictable latency and significant performance improvements for real-time message routing.

The lesson isn't that Go is bad. Go is excellent for most use cases. But for ultra-low-latency, high-concurrency systems, Rust provides a meaningful edge.

The Hybrid Reality

Here's what most articles won't tell you: large companies rarely use just one language.

Cloudflare uses Rust for proxy layers and security-critical components, Go for API services and orchestration. Google uses Go for cloud infrastructure, Rust for Android system components, Python for ML pipelines.

The pattern for startups: start with Python or Node.js for MVP speed, migrate critical paths to Go as you scale, use Rust for specific hot paths that need maximum performance.

Polyglot architecture isn't a compromise. It's the optimal strategy.

My Recommendations

After analyzing all the data, here's my take:

For beginners: Start with Go. Reasonable learning curve, clean syntax, directly applicable to modern cloud development, high demand, good salary.

For JS developers: Stick with Node.js but learn TypeScript seriously. Then consider Go as your second backend language.

For data/ML folks: Python is non-negotiable. Add Go or Rust for production systems where performance matters.

For maximum salary: Invest in Rust. Steep learning curve, but Rust developers command the highest salaries due to limited supply and high demand.

For startup founders: Start with Python or Node.js for speed. Plan to migrate critical services to Go after finding product-market fit.

The Bottom Line

There's no universal "best" backend language. Each excels in different scenarios:

Python → AI/ML, rapid development
Node.js → Real-time apps, JavaScript ecosystem
Go → Cloud-native, scalable services
Rust → Performance-critical, safety-sensitive systems

The right choice depends on what you're building, your team's expertise, scaling plans, time-to-market requirements, and career goals.

*Don't get caught up in language wars. * All four are powerful tools. A good developer knows when to use the right tool for the right problem.

What's Your Take?

Which backend language are you using or planning to learn in 2025? Have you experienced the performance differences firsthand?

Drop your thoughts in the comments. I'd love to hear about your experiences and use cases. 👇

If you found this useful, consider following for more deep dives on backend development and programming languages.

TypeScript 7 is Being Rewritten in Go. This is Microsoft's Biggest Bet on the JavaScript Ecosystem

ridd — Mon, 08 Dec 2025 05:05:23 +0000

Microsoft just did something few developers expected: they're rewriting the TypeScript compiler from JavaScript to Go.

Not a minor optimization. Not a small tweak. A fundamental rewrite that delivers 10x faster performance.

This decision sparked intense debate. Why Go? Why not Rust, which is all the rage right now? Why not C#, Microsoft's own language that was also created by Anders Hejlsberg?

Let's dive deep into what's happening, why it matters, and what it means for you.

The Problem: TypeScript's Growing Pains

Before discussing the solution, we need to understand the problem.

TypeScript has become incredibly popular. According to Stack Overflow's 2024 survey, it ranks among the top 5 most loved programming languages. Adoption has exploded, from small startups to tech giants like Google, Microsoft, and Airbnb.

But this popularity created a new challenge: scale.

Modern codebases are getting massive. VS Code alone has over 1. 5 million lines of TypeScript. Projects like Playwright, TypeORM, and enterprise monorepos can have hundreds of thousands to millions of lines.

The TypeScript compiler, written in JavaScript, started struggling under this weight.

Developers felt the pain daily. Build times stretched to 1-2 minutes for large projects. Editor features like autocomplete and go-to-definition felt sluggish. IDEs consumed gigabytes of RAM. CI/CD pipelines became expensive as build times ballooned.

TypeScript became a victim of its own success.

The Solution: Project Corsa

In early 2025, Microsoft announced Project Corsa, an initiative to port the TypeScript compiler to a native language. The goal was clear: dramatically better performance without changing TypeScript's syntax or semantics.

The language they chose was Go.

The Benchmarks Are Stunning

Let's look at real-world numbers from Microsoft's testing:

Codebase	Size (LOC)	Old Compiler	Go Compiler	Speedup
VS Code	1,505,000	77. 8s	7.5s	10. 4x
Playwright	356,000	11.1s	1.1s	10.1x
TypeORM	270,000	17.5s	1.3s	13.5x
date-fns	104,000	6.5s	0.7s	9.5x
tRPC (monorepo)	18,000	5.5s	0.6s	9.1x
rxjs	2,100	1.1s	0.1s	11.0x

We're not talking about 10% or 50% improvements. This is a 1,000% improvement.

For context, compiling VS Code used to take over a minute. Now it completes in 7. 5 seconds. That's the difference between going to make coffee and immediately continuing your work.

Editor experience improved dramatically too. Project load time for VS Code dropped from 9.6 seconds to 1.2 seconds, an 8x improvement. Memory usage decreased by approximately 50%. Autocomplete and error checking feel nearly instant, even on massive projects.

For developers who spend most of their time in an IDE, this is a game changer.

The Big Question: Why Go?

This sparked the most heated debate in the developer community.

Microsoft had options. They could have chosen Rust, currently very popular and known for performance and memory safety. They could have chosen C#, also created by Anders Hejlsberg, the same person who created TypeScript.

But they chose Go. Here's why.

Native Code with Garbage Collection

The TypeScript compiler heavily relies on garbage collection. Its data structures are complex, with many cyclic references and dynamic memory allocation. Go provides a mature, efficient GC while still producing native binaries.

Rust doesn't have a GC. Porting the compiler to Rust would require fundamental rearchitecture, completely changing how memory management works. That's not a port. It's a total rewrite.

Ease of Porting

The TypeScript compiler's structure turned out to be well-suited for 1:1 translation to Go. Many patterns in the JavaScript compiler mapped directly to Go with minimal changes.

Hejlsberg called this a "plug and play replacement": new code that's functionally identical to the old code, just faster.

Excellent Concurrency

Go's goroutines and channels make concurrent programming simple yet powerful. For a compiler that needs parallel operations (type checking across files, project references, incremental builds), this is extremely valuable.

Mature Cross-Platform Support

Go produces native binaries for all major platforms without runtime dependencies. This simplifies distribution and deployment significantly.

Reasonable Learning Curve

The TypeScript team was already familiar with JavaScript. Go's syntax, while different, is relatively straightforward compared to Rust. This accelerated development considerably.

Why Not Rust?

Rust is undeniably on the rise. SWC, Turbopack, Biome: many modern JavaScript tools are written in Rust.

But for TypeScript specifically, several challenges made Rust less suitable.

Rust's ownership model doesn't align well with the TypeScript compiler's architecture, which relies on GC and cyclic data structures. Using Rust would mean writing from scratch, not porting battle-tested code. Hejlsberg noted that a Rust rewrite would be a "multi-year job," while porting to Go could deliver results much faster.

Why Not C#?

This is the most ironic part. Anders Hejlsberg created C#. Microsoft is the company behind C#. Why not use their own language?

The answer is pragmatic. AOT (Ahead-of-Time) compilation in C# isn't as mature as Go across all platforms. There's also a paradigm mismatch: the TypeScript compiler is very functional and uses many structs, while C# is more object-oriented. Go was considered to have "a little more expressiveness" for the compiler's data structure layout needs.

Community Reactions

The announcement triggered diverse responses across the developer community.

Most developers welcomed the change enthusiastically. The reasoning was simple: performance. Build times dropping from minutes to seconds is something that immediately impacts daily productivity. Many praised Microsoft for making a pragmatic decision focused on results rather than getting caught up in programming language politics.

The Rust community voiced disappointment. Some called it a "missed opportunity," arguing that Rust would provide better memory safety and equal or better performance. With tools like SWC proving Rust works for JavaScript tooling, some questioned why Microsoft didn't follow this trend.

The C# community had mixed feelings. Many found it ironic that the creator of C# wasn't using his own language. Some wondered if this signaled something about Microsoft's confidence in C# for these use cases.

Senior developers largely took a pragmatic view. As one put it: "Language choice is an implementation detail. What matters is the result: a faster compiler, better developer experience. Microsoft delivered that."

The Bigger Picture: JavaScript Tooling Goes Native

TypeScript 7 isn't an isolated event. It's part of a massive trend transforming the JavaScript ecosystem: the shift from JavaScript-based tooling to native compilers.

Consider the timeline. From 2016 to 2019, Webpack and Babel dominated, with JavaScript tooling written in JavaScript. In 2020, ESBuild (Go) and SWC (Rust) started gaining traction. By 2021-2022, Next.js and Turbopack adopted Rust-based tooling. In 2023-2024, Vite became the default with a Rust backend in development. Now in 2025, TypeScript itself moves to a native compiler.

The pattern is clear:

Tool	Language	Function	Speedup vs JS
ESBuild	Go	Bundler	10-100x
SWC	Rust	Transpiler	20-70x
Turbopack	Rust	Bundler	10x+
Biome	Rust	Linter/Formatter	25x+
TypeScript 7	Go	Type Checker/Compiler	10x

An interesting trend emerges. Go tends to be chosen when garbage collection is needed and simplicity is prioritized (ESBuild, TypeScript). Rust tends to be chosen when maximum performance and safety are top priorities (SWC, Turbopack, Biome).

Both approaches produce dramatic improvements over JavaScript-based tooling.

What This Means for You

As a TypeScript developer, here's what you need to know.

What stays the same:

TypeScript syntax remains exactly the same. Your . ts and .tsx files work as before. tsconfig.json remains compatible. The entire ecosystem (libraries, frameworks, tools) continues working.

You don't need to learn Go. You don't need to rewrite code. This is a change in implementation, not interface.

What changes:

Build times decrease dramatically. Editor experience becomes more responsive. Memory usage drops. CI/CD becomes faster and cheaper.

Timeline:

TypeScript 6. x is the last version with the JavaScript compiler. TypeScript 7. 0, targeting early 2026, will use the native Go compiler. A transition period will allow both versions to coexist. Preview builds are available now via @typescript/native-preview on npm.

How to try it today:

Install the TypeScript Native Preview VS Code extension, use the tsgo command from the preview package, or try Visual Studio 2026 Insiders which already includes native TypeScript support.

Long-Term Implications

The ripple effects of this change extend far beyond faster builds.

For the JavaScript ecosystem:

When the compiler is 10x faster, frameworks can perform more compile-time analysis. IDE plugins can provide more real-time feedback. Monorepos with hundreds of packages become more manageable. AI-powered tools can perform deeper semantic analysis.

For programming language trends:

Microsoft's decision validates Go's position as a pragmatic systems programming language. It shows that Go isn't just for backend services and CLI tools. It can compete with Rust for certain use cases. It demonstrates that pragmatism (choosing tools that solve problems over what's trendy) still matters.

For developer tooling:

The era of JavaScript-based developer tools may be ending. When TypeScript, the language used to write developer tools, itself moves to a native compiler, it's a strong signal. Performance can't be compromised. Developer experience is paramount. Native compilation is the future.

My Take

This decision exemplifies excellent engineering pragmatism.

Microsoft didn't get caught up in Rust hype (even though Rust is great). They didn't force C# out of loyalty (even though it's their own language). They didn't stick with JavaScript for convenience (even though that's the easier path).

They analyzed the problem, evaluated options, and chose the solution that best fit their specific needs. The result: a 10x performance improvement that will be felt by millions of developers.

Could Rust have achieved similar results? Perhaps. But with a longer timeline and higher risk.

Will this decision satisfy everyone? No. Good engineering decisions rarely do.

What matters is the outcome: a faster compiler, better developer experience, and a more productive ecosystem. From that perspective, TypeScript 7 is a major win for everyone in the JavaScript and TypeScript world.

What Do You Think?

Did Microsoft make the right call choosing Go over Rust or C#?

Have you tried the TypeScript 7 preview? What's your experience been like?

Will this native compiler trend continue, or does JavaScript-based tooling still have a place?

Drop your thoughts in the comments. I'd love to hear your perspective. 👇

If you found this analysis useful, consider following for more deep dives on developer tooling and the JavaScript ecosystem.