Why China's Tech Giants Moved to Go While Europe Stays on TypeScript

Yongkang Zou · 2026-03-15 · research · Go · TypeScript

Why China's Tech Giants Moved to Go While Europe Stays on TypeScript

An interesting divergence in backend engineering: in China, companies like ByteDance, Alibaba, and Bilibili have been migrating core infrastructure from Java to Go for years. In Europe, most startups still build everything in TypeScript. But the companies that reach real scale, like Lovable and Vercel, end up reaching for Go and Rust anyway.

What's driving this split? And what does the landscape actually look like in 2026?

The China Pattern: Java to Go at Scale

ByteDance's story is the clearest example. In 2014, they introduced Go to solve high-concurrency problems in their push notification services. By 2020, they had refactored their internal RPC framework from Kite (Go v1) to Kitex, designed around performance and extensibility. Today, more than 50% of ByteDance's Go microservices run on Kitex.

Why the move from Java?

  • Goroutines vs threads. Go's goroutines cost ~2KB of stack space. Java threads cost ~1MB. When you're handling millions of concurrent connections for TikTok's push services, this is the difference between 1 server and 500.
  • GC pause predictability. Java's GC (even G1/ZGC) can cause latency spikes in high-throughput systems. Go's GC is designed for sub-millisecond pauses.
  • Deployment simplicity. Go compiles to a single static binary. No JVM, no classpath, no dependency hell. This matters at the scale of tens of thousands of microservices.
  • Fast compilation. Large Java projects can take minutes to compile. Go compiles in seconds, which compounds across thousands of daily deploys.

The CloudWeGo project (ByteDance's open-source Go middleware) includes Kitex (RPC), Hertz (HTTP), and Netpoll (custom network library), all optimized for small-packet, high-concurrency scenarios with coroutine scheduling optimization and TCP parameter tuning.

The Europe Pattern: TypeScript Everything

In European startups, the default stack in 2026 is TypeScript end-to-end: React/Next.js frontend, Node.js or Bun backend, Prisma or Drizzle for DB, deployed on Vercel or Railway.

This makes sense for startups:

  • One language, full stack. Hiring one "TypeScript engineer" instead of separate frontend/backend roles halves your team cost.
  • Shared types. Zod schemas, tRPC, or shared interfaces between client and server eliminate an entire class of bugs.
  • Speed of iteration. From idea to deployed prototype in hours, not days. For a startup burning runway, this is existential.
  • Ecosystem depth. npm has more packages than any other registry. Whatever you need, someone built it.

73% of JavaScript developers now use TypeScript. For I/O-bound services (most web apps), Node.js performance is adequate, async/await handles concurrency well enough, and the developer experience is unmatched.

The Scale Reckoning: When TypeScript Isn't Enough

But companies that hit real scale reach for systems languages. Microsoft rewrote the TypeScript compiler itself in Go (Project Corsa) for a 10x performance improvement. The TypeScript team chose Go over Rust because Go's GC maps better to the compiler's memory patterns and the codebase translates more directly.

Lovable, the Stockholm-based AI coding platform, migrated core backend services from Python to Go for concurrency and throughput. This is a pattern: start fast in a dynamic language, then rewrite the hot paths when you hit the ceiling.

Discord rewrote their Read States service from Python to Rust, reducing tail latency from 400ms to 40ms. By 2026, they've expanded Rust across multiple backend services.

The 2026 Backend Landscape

LanguageStrengthWeaknessBest For
PythonML/AI ecosystem, fastest prototyping10-100x slower CPU, GIL limits concurrencyML pipelines, scripting, data processing
JavaEnterprise ecosystem, mature tooling, JVM optimizationMemory overhead, GC latency, verboseEnterprise systems, Android, legacy modernization
TypeScriptFull-stack sharing, npm ecosystem, fast iterationSingle-threaded, no native compilationWeb apps, startups, BFF layers, serverless
GoConcurrency (goroutines), fast compile, simple deploymentNo generics (before 1.18), limited type systemMicroservices, CLIs, infrastructure, APIs at scale
RustZero-cost abstractions, memory safety, maximum performanceSteep learning curve, slow compilationSystems programming, performance-critical services, embedded

Performance benchmarks in 2026 show Rust is 25-100x faster than Python for CPU-bound work and 2-3x faster than Go, which is 5-10x faster than Node.js. But for I/O-bound services (database queries, API calls), the gaps narrow dramatically.

The Emerging Pattern: Polyglot by Layer

The dominant pattern in 2026 isn't picking one language. It's using each where it fits:

graph TB U[Users] --> TS[TypeScript: Frontend + BFF] TS --> GO[Go: API Gateway + Orchestration] GO --> RS[Rust: Performance-Critical Services] GO --> PY[Python: ML/AI Inference] RS --> DB[(Database)] PY --> DB

  • TypeScript for the frontend and API layer (developer velocity, type safety with clients)
  • Go for orchestration, control planes, and high-concurrency services (the "glue")
  • Rust for latency-sensitive hot paths (inference serving, data processing)
  • Python for ML pipelines and rapid experimentation

This is exactly what we see at companies that have gone through the scaling journey: start with TypeScript or Python for speed, identify bottlenecks, rewrite hot paths in Go or Rust. Not a wholesale migration, targeted optimization.

What I'd Pick Today

Building a startup? TypeScript. Ship fast, hire generalists, iterate daily.

Building infrastructure or handling 100K+ req/s? Go. Simple concurrency, fast deploys, battle-tested at ByteDance/Google/Cloudflare scale.

Building a database, a runtime, or a latency-sensitive service? Rust. The learning curve pays for itself in production stability.

The right answer is almost never "rewrite everything." It's "use the right tool for each layer."

This portfolio (yongkang.dev) uses Go for the API backend and TypeScript for the frontend, which is exactly the polyglot split that makes sense for a content-heavy site with serverless deployment.

References