The stupidity about the "best" Programming language
A common fallacy worth discussing
So, I'm quite certain that you, dear reader, have read an article about the best Programming Languages. And the article looks recommendations look something like this.
- Java? Really not that popular now adays, but still is okay. The installer is like, 6 steps, so that sucks, but it's still good.
Why the argument sucks
Now, given that the core of the argument is: Best language = Popularity - Barrier to entry. Let's discuss why it's a dangerously stupid and fundamentally flawed argument. First off, It's not specific enough, there is zero context. It's horrid argument. Just because many people do something, does not make that something good! In addition, barrier to entry depends heavily on context. The newbie needs a path forward that does have high friction yes, but do not conflate that with popularity.
Let's try and come up with a valid argument here, it's a difficult problem, and we won't get to a final answer today, but let's give it a go.
Let's be more specific
First off, there are a few common use cases for why someone would be asking this question.
- What is a good language to know, to get a job. (IE, the college student)
- What language to learn to have a great career (IE, I want respect and quality)
- What language should I use for my next project
Language requirement to get a job
Best language for your career
How about F#, Clojure or Elm? These are all quality products, relatively speaking of course. Developers using these languages are paid extremely well. I've personally worked with all three of these languages, and I can attest to the quality of these tools. It still depends on the developer of course, but having a quality tool helps by a great deal. They also paid very well accordingly. These aren't easy jobs to get, but it's a career goal worth pursuing.
Best language for my next project
This one is the most difficult question by far, it heavily depends on the use case. It depends on the culture of the company, and the existing codebase. It depends on the quality of the engineers you have available, and the demands of the product.
If the product to be delivered is in the landscape of device drivers, machine level integrations and kernel code. Contrary to public opinion, C++ is a very reasonable recommendation. Another recommendation here would be Rust.
If your building a web API, and a SPA, well, although it's technically possible to build an API in C++, and it's technically possible to transpile C++ into web assembly, that's a pretty... Suspect, approach.
I also, would not recommend using Ruby, Coffeescript, Objective C, visual basic, PHP or C++ for greenfield applications. As they are on the decline, primary on their poor reputations. You would be just setting yourself up for failure when you need to maintain the project in the coming years.
So, what language to use? Do your own damn research. And if your final decision is on the basis of popularity. I challenge you to become better at decision making and critical thinking.
That's all, Stay safe out there folks.
Those languages are on the decline, that means many companies are struggling to find talent, and thus it will be easier to get a job.
I'm not sure about this reasoning. Couldn't it be less popular because companies don't like it anymore? That'd mean there are fewer jobs, but the skilled people are still there to compete for them.
As a rule of thumb, I always have doubts as soon as a "best" claim is made. (best language, framework, orchestrator, service mesh, algorithm, ....) We always need to read this from the writer standpoint:
For the writer specific problem space and context, this is the best he found. Which means that, in these specific conditions, A is better than B or C.
Every time such claims are made, what is interesting is not the "best" itself, but the rationale: why did the writer found this to be the best choice for him.
The conclusion might be different for someone else, because the problem will not be exactly the same, and the context will certainly be very different (e.g. timeframe, alternatives, team composition and bandwidth to adopt a new tech, ...) but if the reasons why the original poster write this is the best - for him - solution are well explained, and described, we usually learn a lot more than just remember «OK this language is the best»
Which is a very long way to repeat what we often say: the best solution will always depend on the problem and context. And although it’s true many solutions are just bad/outdated solutions, there’s no one silver bullet which is the most appropriate solution to all the problems at once (life would be so boring!)