There is no One True Way. The reason there are so many serious languages (and here I deliberately ignore the entire world of
esoteric programming languages) is because they each serve their own purpose.
There may be times when you have extreme performance and memory constraints, such as when working with embedded systems, and in those cases you'd want to be as close to the metal as possible. For that, you have Assembly Language (or direct machine code if you don't want to play with mnemonics) and C. (A good optimizing C compiler, by the way, can often produce tighter machine code than you can in assembly.) Most of the time, though, the skull-sweat involved with manually allocating and deallocating memory and resources, managing pointers and pointers to pointers, and watching bounds and buffers is counterproductive to the whole exercise -- it's best to leave that stuff to proven bottlenecks in large code chunks, since optimization is often a source of what's usually referred to as
write-only code.
For the most part, you'll get more done more quickly and more robustly in a higher-level language. Productivity goes way up with the expressiveness of a language. I wouldn't want to do a whole lot of anything ordinary in APL, but if I found myself having to do a lot of matrix math for any reason, there isn't a better choice -- the language speaks sets and matrices natively.
My preference is for a language that essentially lets you write the language that I'll write my program in. I want my top-level code to be short and to the point (without being overly terse and unreadable). That doesn't mean a metric crapload of import (or using) statements, nor does it mean initializing a bunch of otherwise meaningless object instances (or invoking static class methods) -- it means just writing what the code's going to do with a syntax and vocabulary that makes sense for the code. And each item of that vocabulary (and syntax) that I create ought to be as clear and concise as the code that uses it (as should the vocabulary and syntax used at that level, and so on down the line to the language primitives). Lisp can do that. Heck, even JavaScript can do that. Java can't. (Ubiquity doesn't make it good. There are many better languages than Java that can run on the JVM.)
When it comes right down to it, though, we usually end up programming in the language we
have to use. Sometimes that means using PHP or a .NET language because that's what's available on the web server. As often as not, we'll wind up working in .NET or Java because that's what the corporate infrastructure runs on, or that's what the smart phone runs. Again, that doesn't make the language good, it just makes it the language you have to use.
There's not a lot you
can't do with most languages; to some extent they're interchangeable. It's only when we really have a choice (solo projects or startups we're in charge of) that we really have a choice, and then that choice should be based on what's best for the scale and intent of the project, not on some unreasonable belief that any language is "the best". There is no "best". There is only "the most appropriate".