19 Aug 2025 6 min read My 2 Cents

Don't Chase Ghosts: Why Your Platform's Native Concurrency Is Your Best Bet

Hey everyone,

So, you're a dev, trying to build cool, fast, and responsive stuff. It's inevitable: you eventually wander into the wild world of asynchronous programming. It's a land of promises, futures, and a whole lot of "wait, what's happening now?"

As a veteran in the web-development world who has designed more systems than I can count, I've seen a pattern that keeps bugging me: the mad dash to grab the shiniest new async library, even when the platform you're on already has a great, native way of handling things. And yeah, I'm looking at you, you messy Kotlin coroutine codebases 🫵🏽.

Every Platform Has Its Own Rhythm

Here's the thing about software platforms: they aren't just a random box of tools. They have a philosophy, a core design that shapes everything you build on them. This is especially true for concurrency - how they handle doing multiple things at once. Trying to force a different concurrency model here is like trying to swim upstream - you can do it, but you'll be fighting the current the whole way.

I get the appeal of the new and shiny. A new library drops, everyone on Hacker News is raving about it, and it promises to solve all your problems. But if it doesn't vibe with your platform's natural rhythm, you're just signing up for a headache.

Node.js is all about the Event Loop. If you're a Node developer, you live and breathe the event loop. It's the very heart of the V8 engine. async/await is just some beautiful syntactic sugar sprinkled on top. The whole ecosystem is built around this idea, creating a beautiful, non-blocking dance.
In Go, Goroutines are King. The entire Go universe revolves around goroutines. They're a fundamental part of the language and its runtime. The Go scheduler is a work of art, juggling millions of these lightweight threads without breaking a sweat. The whole standard library is designed for it.

The JVM: A Tale of Two Worlds

Then we get to the JVM. For ages, the mantra was "threads are expensive." And they were! The old "thread-per-request" model could easily bring a server to its knees. This is why amazing, battle-tested libraries like Netty, Eclipse Vert.x, and Project Reactor, along with Kotlin Coroutines, became so popular—they offered a lighter, non-blocking way forward.

Now, you might be thinking, "But Kotlin has built-in coroutine support, so why not use it? The syntax is so much friendlier than Java's old ExecutorService!" This brings up a good point about "idiomatic" code. While Kotlin's launch or async is often praised as the idiomatic way to handle concurrency, we should challenge the idea that idiomatic is always best. Sometimes, the more expressive you can be with your code, the better you can control and understand it.

When you write Kotlin for the JVM, those coroutines aren't truly native to the virtual machine itself. It's a bit like TypeScript in the JavaScript world - a fantastic layer of tools and syntax, but at the end of the day, it all compiles down to what the underlying engine actually understands. The Kotlin compiler is basically sprinkling library magic to create those "coroutines."

But the game has changed. With Project Loom, the JVM now has virtual threads. This is where the real developer-friendliness comes in. You just write normal, simple, blocking-style code. No special keywords, no suspend functions, and no dreaded "function coloring" problem. The JVM handles the magic for you. This means you can use the vast ecosystem of existing Java libraries without worrying if they are "coroutine-aware."

So, in today's world, does it really make sense to pull in a non-native coroutine library? I'd argue that most of the time, you're just adding complexity you no longer need.

The Hidden Costs of Going Off-Road

Sticking to the native path isn't just about being a purist; it's about dodging a whole class of subtle, infuriating problems.

The 3 AM Debugging Nightmare

We've all been there. It's 3 AM, and you're staring at a stack trace that makes no sense. This is where native tools shine. When something is baked into the platform, so are the tools to fix it. Profilers, debuggers, and monitors are all designed to understand the native concurrency model. They know what a goroutine is. They know how the JVM schedules a virtual thread. (Now, if you are one of those that debugs by writing print statements, then you have my condolences.)

When you bring in a third-party library, you're throwing a wrench in the works. Your tools don't speak its language. Suddenly, stack traces are a tangled mess of library internals, not your code. And good luck finding that performance bottleneck. Even worse, these non-native models can mess with things like ThreadLocal variables in Java, leading to bizarre bugs that are almost impossible to reproduce. You're no longer just debugging your code; you're debugging the framework.

The "Async" Virus

The other big headache is how non-native async spreads. You add one suspend keyword, and suddenly it's a zombie plague. The entire call stack has to be updated. The worst part? If a library deep in that chain isn't "coroutine-aware" and makes a normal blocking call, it freezes the whole underlying thread. All that scalability you were chasing? Gone. You're left with all the complexity and none of the benefits.

You know the joke: adding async to a function is like trying to teach a cat to swim. You might get it to work, but the cat will be furious, and you're gonna have scratches all over your face.

It's Not Just About Speed, It's About Safety

Modern native concurrency isn't just evolving to be faster; it's evolving to be safer. A huge part of this is a concept called Structured Concurrency, which is a core principle in Project Loom.

Think of it as a safety net for your async code. It guarantees that if you start a bunch of tasks, they are all contained within a scope. This means:

No Leaked Tasks: It's impossible to accidentally "fire and forget" a task that runs forever in the background.
Simple Cancellation: If you need to cancel the operation, all the child tasks are automatically cancelled too.
Predictable Error Handling: If one task fails, the error is always caught and handled, preventing silent failures.

This is another massive win for sticking with the platform. You get these modern, powerful safety features built-in, leading to more reliable and maintainable code without adding another library.

A Smarter Way to Approach New Tech

Look, I love learning new things as much as the next person. Playing with new tech on personal projects is how we grow. But please, don't just hop on the hype train and shove a new, unproven (by you) technology into a production codebase serving millions of people.

The responsible engineering choice is to battle-test new technologies on your own time first. Understand the quirks and the trade-offs deeply before you propose adding a new dependency to a critical system. Don't introduce risk just to chase the latest trend.

Conclusion: A Healthy Dose of Skepticism

So, the next time you're tempted by a new concurrency model, take a moment. Master the tools your platform already provides. They are almost always the most stable, best-supported, and most seamlessly integrated option available.

And a final thought on marketing. We've all seen those flashy landing pages plastered with the logos of FAANG and Fortune 500 companies. It's tempting to see that as the ultimate endorsement, but it pays to be skeptical. Remember, big companies experiment with new tech all the time. Was that framework used for a mission-critical system, or was it just a proof-of-concept that was later abandoned because the developer experience couldn't compete with more mature tools? There's a reason the "granddaddy" frameworks like Spring are still industry titans. They've survived years in the trenches, proving their reliability and power time and time again, and they work with the platform, not against it.

So, before you import that shiny new async library, just take a breath. See what your platform already offers. More often than not, the simplest and best solution has been right there all along.