For a long time, JavaScript was home.
It paid the bills. It shipped products. It let me build fast and iterate even faster. I understood its quirks, its ecosystem, its culture. I knew how to move inside it efficiently.
So leaving it wasn’t dramatic. It was gradual. Quiet. Almost inevitable.
The more systems I tried to design—systems that needed to last, systems that handled money, logic, state, constraints—the more I felt friction. Not because JavaScript is weak, but because the kind of problems I wanted to solve started demanding a different kind of structure.
JavaScript is flexible. Almost too flexible.
You can model almost anything in it, but the language rarely forces you to model it well. Types are optional. Structure is negotiable. Discipline is cultural, not enforced. That works beautifully when speed matters most. It becomes heavier when correctness, clarity, and long-term maintainability start to dominate your thinking.
I began to care more about invariants than velocity.
More about modeling domain concepts precisely.
More about preventing errors before runtime rather than handling them elegantly afterward.
That’s when Kotlin started to feel natural.
Kotlin doesn’t remove flexibility. It channels it. The type system is expressive without being ceremonial. Nullability is explicit. Data classes feel intentional. Sealed classes make state modeling concrete. Coroutines make concurrency readable instead of chaotic.
It felt like the language was collaborating with me instead of staying out of my way.
And that difference matters.
In JavaScript, I often felt responsible for enforcing structure through discipline and tooling. In Kotlin, structure is part of the environment. The compiler becomes a partner. It questions you. It forces clarity. It catches assumptions early.
As I moved deeper into backend systems and financial infrastructure, this became non-negotiable. I didn’t want clever code. I wanted reliable systems. I didn’t want to rely on conventions to avoid mistakes. I wanted the language to make certain mistakes harder to express.
There’s also something psychological about it.
JavaScript encourages experimentation. Kotlin encourages intention.
JavaScript says, “Try it and see.”
Kotlin says, “Define it clearly.”
Both are powerful. But at this stage of my life, I’m more attracted to clarity than exploration.
I also noticed something subtle: Kotlin slowed me down in the right ways. It made me think about the shape of data, about error states, about the boundaries between layers. It made architectural thinking feel native rather than layered on top.
And that aligned with how I want to build.
Leaving JavaScript wasn’t a rejection. It was an evolution of priorities.
JavaScript taught me how to move fast, how to ship, how to adapt. It gave me creative freedom and access to an enormous ecosystem. I still respect it deeply.
But Kotlin feels like a better foundation for the kinds of systems I care about now—systems where correctness compounds, where constraints are real, where ambiguity is expensive.
In the end, the shift wasn’t about language popularity or career strategy. It was about alignment.
The tools you use shape how you think.
And eventually, you choose the ones that shape you in the direction you want to grow.
For me, that direction pointed toward Kotlin.
— Ebong Billy