Who cares how many languages you "know"? What counts is the things you've built in those languages.

That usually means that you should be focusing on one or two languages, building enough to have "used them in anger", and then figuring out what to do.

It is definitely very worthwhile to get to the depth of at least one language and one framework, because with the scope of what you'd learn about these ones, you will have a frame to more easily understand and learn to use the others, even if you never become expert with the other languages and frameworks you will have to use.

On the other hand, since it takes ten years to become expert, you may not want to wait before starting to learn alternatives. But as a newbie, you don't want to switch to other things too early either. You should have written a couple of non trivial programs (eg. a real application) with a language before you switch to another.

Instead of wondering about this, pick the language you know best now (or if you don't know any, go to udacity/coursera, and take intro to programming with whatever language they use), and start working on a project. After completing a few projects, you will know what to do next.

Pick one where you have a friend who knows it well, and can help you through the pitfalls. Then build something complicated enough that you aren't entirely sure how to do it yet.

"Mastery", "until I know it all", "find which ones I [like]" all kinda fit into this process, so you end up doing them all at once.

I regard it as vitally important that everyone learn the assembly code of at least one instruction set architecture. Not so much because you will ever need to write any, but because all programming languages ultimately result in machine code.

If your java or php or sql or haskell or python suck, the reason your users can tell that they suck, is because your machine code sucks.

The simple awareness of what goes on under the hood will make you better at any language.

Aside from that its helpful to learn several distinctly different paradigms, like python, lisp, c++ and smalltalk.

If by "sucks" you mean "slow", it's probably because of an inefficient algorithm. Knowing assembly won't make you realize you're doing O(n^2) where you can do O(n). These days it's hard to justify learning assembly for someone who's not planning to write high performance low level code, and even there, your time might be better spent learning GPU programming or multithreading.

I do plan on understanding the STG, C--, and Assembler code Haskell compiles to... eventually :)