The Real Cost of an Exotic Choice

It's tempting to pick a language because it's elegant, or fast, or because someone you respect swears by it. For vibe coding specifically, that instinct can quietly sink a project. Here's why: every hour you spend wrestling a niche language's tooling, or untangling AI output that's subtly wrong because the model has seen too few examples, is an hour you didn't spend shipping. The exotic choice rarely fails loudly. It fails as a slow drip of extra fix-loops, missing libraries, and Stack Overflow answers that don't exist.

Concretely, the penalty shows up in three places. First, the AI is less fluent, so it makes more mistakes and is worse at fixing them — and you, not knowing the language, can't tell good code from bad. Second, the ecosystem is thinner, so the library you need may not exist, may be abandoned, or may have no examples to copy. Third, when you get stuck, the web is quieter: fewer tutorials, fewer answered questions, fewer people who've hit your exact wall. With Python or TypeScript, all three of those are non-problems.

None of this means exotic languages are bad. It means the burden of proof is on the exotic choice. If you have a concrete, specific reason — you genuinely need Rust's speed, you're forced into Swift by the App Store, you're extending an existing Go service — then pay the cost with open eyes. If the reason is "it seemed cool," pick the popular option and ship something. You can always rewrite later, and you almost never will, because the popular choice will have done the job.