Niklaus Wirth, one of the pioneers of multiple programming languages, said in 1971:

“[…] the student obtains the impression that programming consists mainly of mastering a language (with all the peculiarities and intricacies so abundant in modern PL’s) and relying on one’s intuition to somehow transform ideas into finished programs. Clearly, programming courses should teach methods of design and construction[…]” —Program Development by Stepwise Refinement

Those words are truer than ever. When I started programming, the battle was between C++ and Basic. Basic was taking over the world, and everyone was now able to do programs. In the same way a lot of people don’t like today’s JavaScript, the exact same thing happened with Basic, with similar complaints about not-so-well-designed language. "My language is better than yours" was often contested with, "My languages allow me to do an application faster than yours." The war shifted to Visual Basic vs. Delphi, then C# vs. Java, and today it's every language against another.

Confirmation bias is the human tendency to search for, interpret, favor, and recall information in a way that confirms one’s preexisting beliefs or hypotheses.

Anchoring is the tendency for an individual to rely too heavily on an initial piece of information offered (known as the “anchor”) when making decisions.

In other words, when you first learn your initial programming language, you will think this is the best language of the world and you will find and favor any information that says so. The funny thing is that from the non-programmer's world point of view, we all are seen as the same, and they all assume we all do the same things, in the same way.

I have learned that each language has its own advantages in specific cases or scenarios. So first, you need to study what problem you need to solve so you can pick the best language, tools, platform, and so on.

There are no silver bullets in software development. If I see that the best solution is outside of my knowledge and experience, I prefer to pass that project. It would be a mistake to try to make it work with the knowledge I have just to take the project.

I want to point out that these types of fights are the reflection of a pride culture that, sadly, a lot of programmers have. It's a good thing to have pride in what you know and what you can do, but when you use that pride to put yourself above the others, then it becomes a hindrance.

A team is needed in order to create quality software, but not separately as siloed teams of developers, testers, and IT personnel. All of them should be treated as a single team, all of them play a specific role, and all are needed. In real world, writing code only is about from 30% to 50% of the total effort needed to deliver the software by the entire team.

It's very human try to distinguish, separate, and make groups of people so we feel important by belonging to the best group and discriminate against the others. I think by now you can see that this culture is very, very toxic in the work environment.

It is not that important which language you use, but about your ability and the skills you develop over time to solve a problem and be able to translate that solution into a thing that the computer understands.

There is no comparison point between the programming languages we use to say which is better than the other since they all have different approaches to solve the problem so the project as a whole can succeed. When developers fight over this they don’t see the whole picture of what is needed to successfully create a program.

Technologies and languages naturally get obsolete. You have to learn programming principals. They transcend any technology, they don’t get obsolete.

So if you allow me, let me give you this advice: avoid at all costs trying to find the best of everything like a religion seeking the truth. There are no silver bullets.

All the languages and tools have their proper advantages and disadvantages, strong points and weak points. The only true way to tell if something is bad or good, or better or worse, is the results that we have. If a language provides better results to do your job (better code, fewer bugs, less time to find bugs, less time to do a program, etc.) then it is a good tool because that's what matters at the end of the day, not which language you use.

Never develop an attachment to a language or tool. The thing that you must focus on is being able to finish your task and give the best results.

“In distinguishing the advantages of warriors’ weapons, we discover that, whatever the weapon, there is a time and a situation in which it is appropriate." —
The 5 Rings by Miyamoto Musashi

Look for these books to help you learn more beneficial skills for your career than mastering a programming language:

Code Complete: A Practical Handbook of Software Construction

The Mythical Man Month

Winning with Software: An Executive Strategy

Rework

Getting Real: The smarter, faster, easier way to build a successful web application

Coders at Work: Reflections on the Craft of Programming

Clean Code

The pragmatic programmer.

Design Patterns: Elements of Reusable Object-Oriented Software

Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability

So instead of fighting over who has the better language, never ever stop learning, always improve your skills, and always find new ways to do a better job. Teach and learn from others, mentor the new devs, and you will find out that you will always learn something new from them. Be a team player, help your developers' community, and try to build instead to fight. You will never reach an end on it.

When you fill that you cannot learn anything more and know everything, you become obsolete.