Skip to main content

Why I Write Code in Multiple Languages — On Purpose

TL;DR​

Switching between Python, Go, JavaScript/Typescript, and others keeps my brain sharp, my code clean, and my bullshit detector strong.

I Started in C# — and I Move Around a Lot​

My background starts with C#. From there, I’ve worked across reactive frontend frameworks (React, Angular, Vue), backend systems (mostly in Python (Django), Node, Go), and tools like test runners or deployment scripts in any language that fits. I don’t “rotate stacks” for the sake of novelty — I switch contexts because you’ll always be working across multiple layers.

Some people argue against multi-language setups, but in my experience, the ideal breakdown looks something like this:

  • Frontend: Stick with one reactive framework for consistency — especially when working with microfrontends or separate frontends per subdomain.
  • Backend: Go — not just for services but for unit testing as well.
  • End-to-end / API tests: Python — fast to write, easy to read, and perfect with requests or httpx.
  • Deployment scripts: Bash. Always Bash. The ultimate orchestrator, lightweight but powerful. With ssh, scp, etc. you are able to extend control beyond your local machine very easily. ...do a build, move stuff around, create files, pull in env vars, create docker images, push it all to remote, do stuff on remote...

I’ve published a project template that reflects this setup (work in progress)

Now, could you swap in Django or FastAPI on the backend? Sure. But here’s my stance:

I prefer tools like sqlc over an ORM. ORMs tend to leak into your schema and constrain your database design, which IMO is paramount. A well-designed RDBMS will outlive the framework, and poor schema choices are often the result of trying to bend your DB around your ORM, not the other way around.

That said — POCs gonna POC, MVPs gonna MVP. You can always rewrite in Go or migrate away from the ORM when it starts showing cracks. What matters is recognizing when you’re making temporary tradeoffs vs building long-term architecture.

And yes, compiled languages will perform better — simply because compile-time can last as long as you want and do as much optimization as you want. Cython is nice. AOT is nicer. Of course, optimal time complexity is table stakes, I'm saying this even though I feel like it should go without saying.

Typecript — Somewhere Between "Useful" and "Why Bother"​

When I’m deep in JavaScript, I ride the wave of IntelliSense’s type inference. Most of the time, it Just Works™. Then I hit one of those weird cases:

  • A utility function expects an object of a certain shape
  • I only ever called it in one place
  • But now I’m reusing it elsewhere and the object’s shape is just slightly different

Perfect time to add types, right? In theory, yes. In practice — full JS codebase, setup overhead, and JSDoc helps a little but not enough.

So I think, "Maybe I’ll try TypeScript again." I do. I refactor, get things compiling. It feels great — until it doesn’t. I remember why I dropped it last time: too much friction for the actual gain in the way I write code.

So I have 7 YOE in Typescript equivalent about 10 months real xp, lol.

Python — Somehow, Type Hints Stick​

Oddly enough, Python’s type hints do work for me. Maybe because they’re opt-in. Maybe because tools like Pylance, TypedDict, and minimal class-based types hit that sweet spot:

def with_perf(text: str | None = None) -> Callable[[F], F]:
    ...

Even when Pylance complains about something that works (like conditional decorators), I know what I’m doing — the linter is a guide, not a gatekeeper.

It’s not about being strictly typed. It’s about getting just enough signal to go faster without overcommitting to boilerplate.

Vue / React — Watch, Computed, and Inline Everything Fatigue​

Modern Vue Composition API and React with Hooks are… similar. And both suffer from the same thing:

"watch(something, something, something, I forget the order, let me check the docs again."

So I default to something like:

function onUserChange(val) {
  ...
}

watch(user, onUserChange)

It’s clearer. Easier to reuse. Easier to debug. And most importantly: I know what’s going on without diving into docs or trying to trace anonymous arrow functions.

ES6 didn’t help here. The everything-inline culture makes it harder to name functions, trace stack frames, or even know what you’re passing around.

Go — The Return of Clarity​

Go snaps me out of my dynamic habits. It forces me to be more explicit about types. I'll start adding interfaces in python to define the shape I'll get back:

class SomeObjCreateRes(TypedDict):
    some_obj_id: int
    a_prereq_obj_also_created_id: int
    another_prereq_obj_also_created_id: int
  • Not the actual names obviously... this might be like user_id, article_id, comment_id, tag_id, etc. ...entities obviously depend on the domain.

When I write Go for a while, my JS and Python code gets better. It’s like mental palate cleansing.

The Real Benefit: Intent​

Writing in multiple languages reminds me that I don’t have to accept the way a framework or language wants me to do things. I can:

  • Borrow what’s good
  • Question what feels off
  • Structure my code around what’s clear and intentional, not just idiomatic

I’ve found that I write faster, clearer, and more maintainable code when I’m constantly switching contexts.

It’s not about being a polyglot. It’s about not getting stale.