DEV Community: Shinya Saita

How to answer "Why did you pick this language?" so people actually nod

Shinya Saita — Mon, 10 Aug 2026 16:17:55 +0000

You've been in this meeting, right?

Every new project starts with the same ritual: picking the stack. Requirements and architecture get all the attention, but "what do we build this with?" matters just as much.

So your team debates it properly. You weigh the options, land on a choice, and everyone agrees: "Yeah, this is the right fit for us." Then you present it in a review meeting, and someone — a manager, a stakeholder, an architect from another team — asks:

"Why did you choose this language?"
"Would another language not have worked?"

If reading that made your stomach drop a little, keep scrolling. 😅

Here's the thing I wish someone had told me earlier: this question is not an attack, and it's not someone doubting your skills. What the asker actually wants to know is much simpler:

"Is this decision sound from a business perspective?"

Let me put one disclaimer up front:

There is no absolute ranking of programming languages.

This is not a "language X is better than language Y" post. But every language that survives has reasons it keeps getting chosen — and whether you can articulate those reasons out loud is the entire game.

I've been asked this question many times across my career. For years I answered with technical merits, and every time I got the same politely unconvinced face. Eventually it clicked: what's really being tested isn't "is it the most modern?" or "is it the fastest?" It's:

"Can you explain this choice to a third party, in business terms?"

That's what this post is about. By the end, I hope you'll feel ready to walk into your next review and defend your stack with confidence.

What decision-makers are actually evaluating

When engineers talk tech selection, we gravitate toward performance, modernity, and trends. Those matter. But the people approving your proposal are usually worried about something far more mundane — and far more long-term:

Can we hire and hand over this codebase years from now?
Can we maintain it without heroics in year three?
Will it survive spec changes and reorgs?
Does the cost actually pay off?
Does the project depend on one irreplaceable person?

Looking back at projects I've been on, these are exactly the things nobody worried about at kickoff — and everything that quietly hurt later.

A language with a steep learning curve slows down every onboarding. A team of three can absorb that; a team of fifteen can't. And a niche technology means one resignation can destabilize an entire project.

Which leads me to the definition I now use:

Tech selection isn't picking the best option for this moment. It's making a choice you could re-explain to your future self in three years — and still nod at.

"This language is trending and I want to try it" is a fine reason to start a side project. It's a terrible reason to bet a product on.

Languages that keep getting chosen have reasons

Across the languages that survive decades in production, the same traits show up:

Easy to learn — new members become productive fast
Easy to build with — you spend time on the actual problem
Easy to operate — the thing stays maintainable after launch

(Plus domain-specific strengths: easy to build securely, easy to squeeze hardware performance, and so on.)

In an industry this trend-driven, anything still standing after 20 years is not standing out of inertia.

I spent the longest stretch of my career in PHP shops, so here's an example from that world: WordPress and MediaWiki (the software behind Wikipedia) are PHP. What they share isn't elegance — it's that they've been continuously maintained for decades. A language's longevity directly becomes the longevity of the products built on it.

And this isn't a PHP thing. Python's machine-learning ecosystem, TypeScript's grip on frontend, Go's dominance in cloud-native infrastructure — each has clear, articulable reasons it keeps being chosen.

What matters is whether you can explain, in your own words, why your language keeps being chosen.

The 4 lenses of defensible tech selection

Here are four lenses that work regardless of language. If you can answer "why this language?" along these four axes, you'll convince most rooms.

Lens 1: Talent depth — can you avoid a bus factor of one?

The most overlooked question in tech selection: how many people in the market can write this?

A language with a large developer population gives you options — for hiring, for mid-project reinforcements, for handovers. Choose something niche and you've signed up for "if this person leaves, we're stuck."

For example:

Python — huge population across data science and web; lots of career-changers learning it, so the hiring funnel is wide
TypeScript — effectively the lingua franca of frontend; JavaScript developers convert easily
Go — growing fast among infra-leaning engineers, though the pool for business-app web development is still thin in some markets

Choose with "can the team keep shipping?" in mind, not "do I love this language?". It's unglamorous, and it's the foundation everything else stands on.

Lens 2: Fit for purpose — is this the shortest path?

Every language has home turf. Yes, most modern languages can technically do anything — but whether they get you to your goal by the shortest path has a huge impact on productivity.

"I just want to write business logic, but my week is disappearing into environment setup and plumbing..."

Sound familiar?

Building a web application? Pick a language whose ecosystem naturally speaks HTTP, sessions, and templating
Data processing / analytics? Very little competes with Python's ecosystem (pandas, NumPy, ...)
High-throughput API servers? Go's concurrency model earns its keep
One type-safe language across frontend and backend? That's the realistic case for TypeScript

If you can say "this language is specialized for — or at least strongly aligned with — what we're building", your proposal gets dramatically more persuasive.

Lens 3: Ecosystem maturity — will you reinvent wheels?

Modern development runs on frameworks and libraries. Auth, validation, email, background jobs — whether these come ready out of the box directly determines your velocity.

Python — Django, FastAPI. Django's "batteries included" philosophy ships an admin UI, ORM, and more from day one
TypeScript — Next.js, NestJS. The full-stack-in-one-language ecosystem has genuinely matured
Go — an excellent standard library; you can go far without a framework, but business-app "we also need this and this and this" features often end up hand-rolled

And here's the part people miss: ecosystem maturity isn't just about building fast.

It's about surviving change.

With a mature framework, a spec change means a small adjustment, not a rewrite. That's what lets a team keep moving without flinching.

Lens 4: Cost and operations — can you keep this running?

The final piece is total cost — not just infrastructure, but operations, incident response, and salaries. Think ROI, not hosting bill.

Does it need a special runtime or environment?
Does it run on a simple infrastructure setup?
Can you start small and scale later?

Being able to say "we can start cheap, and it holds up if we grow" carries enormous weight with business decision-makers. It's not flashy — but for anything meant to run for years, "sustainable without heroics" is priceless.

The inevitable question: "But is it fast enough?"

Whenever languages get compared, this one shows up. And yes — some languages extract more from the CPU than others.

But look at where most web applications actually spend their time:

Database access
External API calls
Network latency

The raw execution-speed gap between languages is the bottleneck far less often than people assume.

Of course, if you're building real-time systems or handling massive concurrent connections, the calculus changes. But for most business systems and web services, architecture and query optimization move the needle far more than language benchmarks ever will.

The mature answer isn't "this language is fast" — it's: "For these requirements, is language performance actually going to be the bottleneck?" Usually, it isn't.

When you're asked to compare — compare like this

"How does it stack up against language X?" is unavoidable. The goal is not to win a technology debate. It's to explain the lowest-risk business choice.

Here's my rough mental cheat sheet for commonly compared languages:

Language	Strength	Watch out for
Python	Low learning curve, unmatched in AI/data	Large-scale web apps need deliberate architecture
Go	High performance, great concurrency	Business web apps mean hand-rolling things frameworks give you elsewhere
TypeScript	One language across the stack, type safety	Fast-moving ecosystem; dependency management needs discipline
Rust	Safety and performance	Steep learning curve, harder hiring

(Disagreements welcome in the comments 😄 — this is my experience, not a benchmark.)

No language is perfect. Which is exactly why the winning move is explaining "given our constraints, this is the best fit" — from the listener's point of view.

The ready-to-use script

"Okay, I get the theory. What do I actually say?" Here's a template you can deliver calmly in one to two minutes:

For this project, we selected the technology based not just on performance or trends, but on long-term operability and fit with our organization.

[Language] has [track record / market share], including long-running production systems like [concrete product examples].

We chose it because the large developer population keeps hiring and handover risk low, and because it specializes in [the language's home turf], giving us a good balance of learnability, implementation speed, and maintainability.

We did evaluate alternatives, but for these requirements, [language] was the lowest-risk choice in terms of speed, cost, and continuity.

Example: making the case for Go

For this project, we selected the technology based not just on performance or trends, but on long-term operability and fit with our organization.

Go is widely adopted across the cloud-native landscape — Kubernetes and Docker are written in it — with a strong track record of long-running production systems.

We chose it because its simple language design keeps code consistent across engineers, and its concurrency performance matches the requirements of our API platform.

We also evaluated Python and TypeScript, but for these requirements, Go was the lowest-risk choice in terms of speed, cost, and continuity.

Notice the framing: not "we picked the most impressive option" but "we picked the lowest-risk option." Decision-makers relax at the second one, not the first.

And there's a bonus effect: even if the answer is still "no," a structured explanation like this makes it obvious which specific concern is blocking approval — so your second attempt becomes a targeted fix instead of another shot in the dark.

Tech selection is accountability to your future self

If I had to compress this whole post into one line:

Tech selection isn't choosing what's most impressive today. It's making a decision you can still explain — and stand behind — years later.

You've probably heard (or been the subject of) the line: "They can build things, sure, but they never think about operations." I've been on the receiving end of that one. It stings because it's fair: being right today isn't enough.

And if you're drawn to a language because it's trending or because you want to learn it — protect that curiosity, it's what keeps this job fun — but on its own, it won't get a proposal approved. Pair it with a business case built on the four lenses:

✅ Deep talent pool — low bus-factor risk
✅ Fit for purpose — shortest path to the goal
✅ Mature ecosystem — no wheel reinvention
✅ Realistic cost and operations — sustainable for years

Cover those four, and you can propose any language with your head held high.

Now go pitch your stack.

This article is an English adaptation of a piece I originally wrote for the pamphlet of PHPerKaigi 2026, a Japanese PHP conference, later reworked for Qiita (Japanese).

I got tired of heavyweight Markdown editors, so I built one in Rust + Tauri that doesn't ship a browser

Shinya Saita — Mon, 10 Aug 2026 16:06:49 +0000

TL;DR: I wanted a Markdown editor that just opens instantly and gets out of the way. Nothing quite fit, so I built Bokuchi with Tauri v2 + Rust + React. Instead of bundling a whole Chromium instance, it renders through the OS's native WebView — so it's light enough to leave open all day and opens before you finish reaching for your coffee. It's open source: github.com/Bokuchi-Editor/bokuchi

The itch

Here's a situation you probably know too well.

You want to jot down a quick note. Maybe a release checklist, maybe a snippet of Markdown for a PR description. So you open your editor of choice — and your laptop fan spins up like it's about to take off. A "note-taking" app just claimed a serious chunk of your RAM before you typed a single character.

I love VS Code. I've used Atom (RIP). I respect Obsidian. But for the specific job of "open a window, write some Markdown, close it", they all felt like renting a moving truck to carry a sandwich.

I had three requirements, and only three:

Simplicity — Markdown editing. That's it. No plugin marketplace, no account, no sync daemon.
A design I won't get tired of — minimal, calm, something I'd happily stare at all day.
Speed above all else — this was non-negotiable. It has to feel instant.

I looked around. I couldn't find the thing that hit all three. So I did what every engineer eventually does when they should probably know better:

I decided to build it myself.

Why "build your own" is the developer's disease

Building your own tool is a trap and a joy at the same time.

It's a trap because "how hard can a text box be?" is one of the great lies we tell ourselves. It's a joy because the moment your own tool does exactly the thing you wanted, in exactly the way you wanted, there's nothing else like it.

The real question wasn't "should I build it" (my ego had already decided). It was "what do I build it with?"

If I reached for Electron, I'd be right back where I started: shipping a whole Chromium instance to render a text area. That defeats requirement #3 before I write a line of code.

Enter Tauri.

What is Tauri, for the uninitiated?

If you haven't touched it yet:

Tauri lets you build desktop apps with a web frontend and a Rust backend. The key difference from Electron is that Tauri doesn't bundle a browser. Instead it uses the operating system's native WebView (WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux).

That one design choice cascades into everything I cared about:

Tiny footprint — no bundled Chromium means dramatically smaller binaries and lower memory.
Rust backend — safe, fast, and genuinely pleasant for file I/O and heavier logic.
Security by default — the app can only touch the OS capabilities you explicitly grant it (more on this below).
Cross-platform — one codebase for Windows, macOS, and Linux.

For a "must feel instant" Markdown editor, this was the right foundation.

Meet Bokuchi

So I built Bokuchi — a lightweight, cross-platform Markdown editor.

Stack:

Layer	Choice
Framework	Tauri v2
Backend	Rust
Frontend	React + TypeScript
Build	Vite
Platforms	Windows / macOS / Linux

Light enough to forget it's running

I originally wanted to open this section with a big, satisfying RAM number. I'm not going to — because honestly measuring memory for a WebView-based app is murkier than it looks. Do you count the OS's WebView helper processes? Shared frameworks already resident because the system uses them anyway? Depending on where you draw the line, you can make the number look heroic or ordinary, and I'd rather skip the benchmark theater.

So here's the claim I can stand behind: Bokuchi doesn't bundle a browser. There's no Chromium instance spinning up just to render a text area — the UI runs in the WebView your OS already ships. In practice that means it opens instantly, idles quietly, and never gives you a reason to close it.

That's not a spec-sheet flex — it's the entire reason the app exists. When opening the editor costs you nothing, you actually use it for the two-line notes instead of reaching for a sticky note.

What's actually in it

I kept the core minimal, but "minimal" doesn't mean "bare":

Real-time preview with synchronized scrolling
Tab management + auto-save + state persistence (close it, reopen it, everything's where you left it)
Markdown toolbar — headings, bold, italic, lists, links, tables
Search & replace with match highlighting
KaTeX for math ( $...$ and $$...$$)
Mermaid diagrams from fenced code blocks
Marp slide presentations with custom themes
CJK-aware word count (yes, it counts Japanese/Chinese/Korean characters correctly)
9 themes and a 14-language UI
HTML export, plus HTML/TSV/CSV table → Markdown conversion

The feature I'm quietly proud of: a variable system

Here's the part that started as "a small convenience" and turned into my favorite feature.

I write a lot of repetitive documents — release procedures, runbooks — where the structure is identical every time but a few values (a date, a version, a command) change. Copy-pasting last week's doc and hunting for the three things to update is exactly the kind of small, dumb friction that adds up.

So Bokuchi lets you embed variables directly in your Markdown:

<!-- @var version: 2.3.0 -->
<!-- @var deploy_date: 2026-07-01 -->

# Release Procedure {{version}}

Scheduled for **{{deploy_date}}**.

Run:

    git checkout v{{version}}
    ./deploy.sh --version {{version}}

Define once at the top, reference with {{...}} anywhere, and the preview renders the resolved document. Variables can be file-local (like above) or global (set once in Settings, reused across every file). No spreadsheet, no find-and-replace ritual — the template is the document.

Security: you grant, or it can't

One thing I genuinely appreciate about Tauri v2 is that access to the host machine is opt-in. Your app declares a set of capabilities, and anything not on the list simply cannot be called from the frontend.

A capabilities file looks roughly like this:

{
  "identifier": "default",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "dialog:default",
    "fs:allow-read-file",
    "fs:allow-write-file",
    "clipboard-manager:allow-read-text",
    "clipboard-manager:allow-write-text"
  ]
}

The frontend can open a file dialog, read and write files, and touch the clipboard — because I said so, explicitly. It can't spawn a shell or hit the network unless I add those permissions. For a tool people run on their own machines, that "least privilege by construction" model is exactly the guarantee I want to be able to make.

The Tauri v2 developer experience

A few honest takeaways after shipping with it:

The web frontend is just the web. React, Vite, hot reload — all the muscle memory transfers. No weird framework-specific rendering layer.
Rust is where the calm lives. File I/O, external-change detection, the variable resolver — pushing that into a typed, compiled backend meant a whole class of "undefined is not a function at 2am" bugs never happened.
The capability model makes you think about your surface area early, which sounds like a chore and is actually a gift.
The lightness is real. Not bundling Chromium shows up exactly where you'd hope: smaller installers, faster startup, and an app you can leave open all day without thinking about it.

Is it all frictionless? No — you'll spend time learning the permission system, and WebView differences across platforms are a real thing you have to test. But for the class of app where "lightweight" is a feature and not an afterthought, Tauri v2 is the most fun I've had building desktop software in years.

Try it / break it / star it

Bokuchi is free and open source.

Download (auto-detects your OS): bokuchi.com
Source & releases: github.com/Bokuchi-Editor/bokuchi

If you've ever grumbled at a note-taking app for hogging your RAM, I'd love for you to give it a spin. Issues, feedback, and PRs are all genuinely welcome — and if it saves you a little friction, a ⭐ on the repo helps more people find it.

Thanks for reading. Now go write something. Quickly.