DEV Community

Cover image for Is the language war even real?
ujja
ujja

Posted on

Is the language war even real?

Every few years, the tech world seems to restart the same argument. Java vs C#. Python vs JavaScript. Backend vs frontend. It shows up in blog posts, conference talks, comment sections, and sometimes quietly inside engineering teams.

There is often a subtle smirk when someone mentions a different stack. An unspoken belief that one choice somehow reflects intelligence, experience, or superiority.

Over time, I have started questioning whether this so-called language war is even real, or if it is something we keep alive out of habit and ego.

The quiet rivalries we rarely acknowledge

Let us be honest, these rivalries exist. You can feel it between C# and Java developers, and just as clearly between Python and JavaScript folks. Sometimes it is playful and harmless, driven by memes or community culture. Other times, it becomes personal.

When that happens, the conversation stops being about tradeoffs or problem-solving. It becomes about identity. The moment a language turns into a badge instead of a tool, comparison becomes inevitable. Not a comparison of solutions, but a comparison of people.

A recent experience that made me think

I was working in a team led by someone deeply rooted in C#, while my background was primarily Java and Golang. From the beginning, there was tension that had nothing to do with delivery or capability. The work was getting done. Expectations were being met. Yet scrutiny was constant.

I was repeatedly called out for very minor things. Formatting choices. Small stylistic preferences. Slightly different approaches that were still valid and correct. The feedback rarely felt like mentorship. It felt like harassment over minuscule details, almost as if finding faults was a way to feel superior.

What stood out was not the feedback itself, but the intent behind it. It did not feel like an effort to improve the codebase. It felt like an effort to establish dominance based on language familiarity.

That was the moment I realised this had very little to do with Java, Golang, or C#. It was about someone tying their sense of value to a specific language.

When a language becomes part of your identity

This is where things start to break down. When developers treat a language as an identity rather than a medium, any alternative feels like a challenge. Technical discussions slowly turn emotional. Curiosity gives way to defensiveness. Learning gives way to gatekeeping.

Instead of asking why a particular approach was chosen, the focus shifts to proving that one stack is inherently better than another. That mindset does not build better systems. It builds fragile teams.

Fundamentals matter more than syntax

In reality, fundamentals matter far more than any language ever will. Data structures, algorithms, system design, networking basics, concurrency, memory management, and debugging skills do not belong to any single ecosystem.

The ability to reason about tradeoffs, read documentation critically, and write code that another human can understand months later is what defines a good engineer. These skills outlive frameworks, trends, and even entire languages.

In today’s world, engineers are expected to adapt constantly. New languages and tools appear all the time. The language is simply how ideas are expressed. If the fundamentals are strong, switching languages is uncomfortable, but not threatening.

Does the language actually matter

Yes, it matters in practical terms. Ecosystem maturity, tooling, performance characteristics, and team context all play a role. Choosing a language is an architectural decision.

But using a language choice as a measure of intelligence or engineering depth makes no sense. That is not confidence or expertise. That is insecurity.

Strong engineers respect constraints and context. Weak ones flex preferences.

Why the language war feels pointless

Most real-world problems do not care what language solves them. Users do not care. Businesses do not care. Production incidents definitely do not care. They only care whether the system works, scales, and can be maintained by the next person who touches it.

The language war mostly lives in online arguments and fragile egos. The strongest engineers I have worked with were language agnostic. They focused on clarity, reliability, and learning. They did not smirk. They asked questions.

At the end of the day, languages are tools. Fundamentals are leverage. Ego is just noise.

Top comments (20)

Collapse
 
richardpascoe profile image
Richard Pascoe

Luckily, I have always been able to avoid such "wars". Perhaps it's because I settled into Python early on - becoming a self-confessed Pythonista in the process.

As I'm now considering dipping my toes into game development, I am looking towards Godot Engine mostly due to the fact that GDScript is similar in syntax to Python.

If you enjoy the language you're using and you are able to leverage it the way you need, then that is probably enough for most people.

Collapse
 
ujja profile image
ujja

That makes a lot of sense. Python tends to attract a more pragmatic mindset, which probably helps avoid a lot of unnecessary comparison.

I like what you said about enjoyment and leverage. If a language lets you express ideas clearly and get things done, that already solves most problems. Godot and GDScript sound like a natural transition, given your background, too.

I think issues start when people stop seeing languages as enablers and start treating them as a measure of worth. Your approach feels refreshingly grounded.

Collapse
 
richardpascoe profile image
Richard Pascoe

I guess I'm lucky in that as I'm still a fledgling Pythonista in my own eyes, I don't see the need or have the desire to become involved in such "wars".

Perhaps one of the reasons some of these arguements start is also down to marketing and FOMO - much like the current AI bubble. A new language or stack gains enough attention and some of us become concerned we're missing out?

Thread Thread
 
ujja profile image
ujja

That’s a really good observation. I think FOMO and marketing play a much bigger role than we like to admit.

A lot of the anxiety isn’t really about the language itself, but about relevance. Nobody wants to feel like they’re falling behind or betting on the “wrong” thing. When a stack gets enough hype, it’s easy to confuse popularity with necessity.

What I’ve noticed, though, is that solid fundamentals age far better than chasing trends. People who understand concepts deeply tend to adapt just fine, regardless of which wave comes next. The hype cycles come and go, but that core skillset sticks.

Thread Thread
 
richardpascoe profile image
Richard Pascoe

You’re absolutely right, Ujja - fundamentals and a solid foundation will always matter. Whatever my thoughts on "vibe coding", I just hope that those starting out on that path also take the time to focus on the fundamentals.

Thread Thread
 
ujja profile image
ujja

Agreed. Vibe coding is fun, and fundamentals still matter.

Without them, things work until they don’t, and no one knows why. With them, new tools just make you faster, not confused :)

Thread Thread
 
richardpascoe profile image
Richard Pascoe

Exactly this - at the end of the day, fundamentals are there for a reason!

Collapse
 
sebhoek profile image
Seb Hoek

Good points, and I agree. In bigger organizations, languages matter. Not because one is cooler than the other, but because we look at a huge portfolio of existing applications, a work force and their skill set, an existing talent pool outside the organization, the maturity of the language's eco-system, security, vulnerabilities and risk management, and of course upcoming migrations. Bigger organizations seem to spend most of their efforts migrating from one legacy platform into the next. And that's what business cares about - as you said - a stable, maintainable, robust and affordable IT landscape.
That's why you don't walk into a big organization and introduce Scala without being shouted at.

Collapse
 
ujja profile image
ujja

Completely agree with this, and I am glad you called it out.

In larger organisations (especially banks), language choice is rarely about preference or trends. It is about portfolio size, existing systems, available skills, hiring realities, risk management, and long-term maintainability. From that lens, consistency often matters more than novelty.

That still fits well with my point, though. Those decisions are architectural and business-driven, not ego-driven. Problems arise when language choices are framed as personal superiority rather than as organisational trade-offs.

And yes, walking into a large enterprise and casually suggesting Scala would definitely not end well :)

Collapse
 
embernoglow profile image
EmberNoGlow

When I hear such comparisons or questions like "why do you use this or that language?", I sometimes think of assembly language... I'd love to see how those who compare languages ​​actually write in assembly language (assuming they've never tried it, of course). In 99% of cases, I think they'll stop nitpicking. And of course, they'll eventually say how much worse (inconvenient) assembly is than high-level languages.

Collapse
 
ujja profile image
ujja

That is a great point, and assembly is a perfect reality check.

The moment you zoom out far enough, most language arguments feel a bit silly. High-level languages exist specifically to abstract complexity so we can focus on solving problems, not fighting the machine.

As you said, once someone has even a basic appreciation of what sits underneath, nitpicking over syntax or minor differences suddenly feels far less important.

Collapse
 
derekcheng profile image
Derek Cheng

I suspect more important than the language itself is the ecosystem around it: the maturity and richness of tooling, frameworks, conventions, and those things have a meaningful impact on productivity. In this age, the other thing is the prevalence of that language in LLMs' training sets!

Collapse
 
ujja profile image
ujja

I agree, the ecosystem around a language often has a bigger day-to-day impact than the language itself.

Tooling, conventions, frameworks, documentation quality, and community practices all influence productivity and maintainability in very real ways. Two teams using the same language can have wildly different outcomes depending on those factors.

Your point about LLM training data is also interesting. That is becoming a real consideration now, whether we like it or not, especially when it comes to discoverability and support.

Collapse
 
ulitroyo profile image
Uli Troyo • Edited

I think the problem is friction. Two examples:

Java

For years I heard so many bad things about Java, about how slow and boilerplate-heavy it is. Then I had to use it. Came away thinking it was nice! It's easy to pick up, it works as you expect, it has good modern tools, and if you use modern syntax, it's not particularly wordy. When a YouTuber I follow had a similar good experience while building a game with Java it cemented my feelings for the language: it's so simple and... sufficient? ...that I just like working with it. I can see why so many GUI business tools are written with it. It feels frictionless for me.

Python

By contrast, Python, which is a lot easier to use than even Java, kinda grinds my gears. It feels like a scripting language cosplaying as a systems language. I don't like it. Nushell is such an excellent and OP scripting language that Python doesn't fit this use case for me anymore. Then Bun is such an excellent runtime for a language I'm far more well-versed in, that Python doesn't fit the use cases that Nushell doesn't. And then, Python tooling is unnecessarily clunky. I was happy to find out uv supports Nushell (which almost nothing does) but dislike that it wants to seize my shell for its weird REPL... and compared to Cargo, NPM or Gradle, Python/uv feels... meh. Then for other systems-level things, Python is just too slow... I'd much rather use Zig or Rust or C or C++. But Python has such a rich ecosystem that don't want to avoid it. I like Python, I recommend it to beginners all the time. I just seldom wind up using it at all, because there are so many languages I'd rather use for each thing I could use python for. It's too much friction.

Oh yeah... TypeScript

I don't know why I went with Python as my example for friction, when ultimately I like it. By contrast... TypeScript???? You people use THIS over JavaScript???? WHY???? I guess I didn't think of TypeScript earlier because I avoid thinking about it as much as possible. How is THIS what y'all like to write? Your idea of fixing JS--which is a perfectly enjoyable scripting language as it stands now--is to make the language wordier, uglier, slower, more complex, and necessitate a transpilation step??? Why. And your linter wants me to use "===" when I know "==" suffices? Dang it, you're too numerous, now you're in my LSP. I haaaaate TypeScript, and I'm only telling you because I'm aware that by all metrics I'm the one with the fringe opinion (and because I'm not that serious, it's fine, bad taste never killed anyone I think). As for me, for whatever unpopular reason, I enjoy JS quite a bit, while feeling enough friction from TS to grind my gears to shapeless metal.

And of course, because we're all different, each of us will feel some friction using one thing over another, for vastly different and often very silly reasons. And it's fine, and kind of fun. And interesting! It's why I think there's always value in creating new languages. I understand the value propositions of Zig and Nushell and Bun and Roc over their alternatives, because I'm me and I know what I like. I've know people who have used Java 8 or PHP quite happily their whole career. There are those of us who are nerdy about what we like, and those who are joyfully complacent... or zealously invested. I get the language wars: we're human, and we identify pretty strongly about our choices--even our choices to be noncommittal, weirdly.

Collapse
 
ujja profile image
ujja

This is a really good way to put it. Friction explains way more than right vs wrong ever does.

Your Java example especially hits. So many opinions are just inherited until someone actually uses the thing and goes wait this is… fine? Maybe even nice. Once the friction drops the whole narrative changes.

And your Python and TypeScript takes kinda prove the point too. Same language can feel smooth or unbearable depending on what you want to do and what you are already comfortable with. That has nothing to do with skill or intelligence. It is just fit.

I think the problem starts when friction turns into identity. Liking or disliking a language stops being a preference and starts being a personality trait. That is when curiosity dies and everything turns into taste wars.

Also the TypeScript rant made me laugh 😄 even if I do not fully agree which is honestly the point. Sometimes a tool just grinds your gears and that does not need a philosophical defence.

Appreciate the thoughtful reply. This kind of nuance is way more interesting than the usual language war noise.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.