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!)