The first thing you have to do when learning a new programming language is to search for the standard libraries. All of them come with a core standard library (often mistaken by the language's syntax) and an optional set of standard libraries and high-quality third-party libraries that you must know before writing your own.
Some languages are more restrict with what goes into the optional standard library than others. For instance, to get something into the C++ STL takes years of discussions but uploading a module into CPAN takes seconds. The most important is building your network of trust while you develop applications, asking fellow developers for their recommendations and trying yourself all the options to choose the best for you.
Below is a very personal list of libraries and my own level of trust and quality for them. I've tried to follow the common sense of the developers in that particular language but again, everyone chooses his own common sense.
The C standard library: Extremely powerful but sometimes dangerous. Don't try to recode pointer or memory manipulation, mathematical functions, date and time stuff. But be aware that most common functions like strcpy, strcat and similar can lead you to security breaches (buffer overflow) and must not be used. Don't try to rewrite them or build wrappers around too, they DO have their own secure versions, usually with an n in the middle like strncpy and strncat. Be sure to read the man pages before you use the libraries, they have all the information including security issues.
The Standard Template Library: The STL is quite possibly the finest standard libraries in existence. Every container, every algorithm, every iterator was defined and developed using state-of-the-art programming concepts and algorithms reaching a level of almost perfection. Generally, if the performance of the STL does not suits you it means that you have to go down to C structures and algorithms and use the C standard library. It's normally a better idea to conform your classes and lists to STL than to do it your way because of fine-tuning, you'll probably loose in performance.
Gnu libraries: In addition to the standard library, Gnu has provided an extensive list that you get for free when using the GCC compiler. The quality is as good as the C standard library and sometimes is considered part of it. Gnu also has a very good scientific library called GSL.
The boost library: Extremely high quality third-party libraries. It's designed as an extension to the STL with more generic algorithms and data structures not covered by the STL. Everything was modeled using STL concepts, all containers and algorithms follow exactly the same logic so if you understand the concepts in STL you should easily understand the boost library.
Gtk/Qt: Very good quality graphical libraries specialized in desktop applications. They handle not only windows and buttons but also inter-process communication, hardware events and 3D graphics. The two major window manager for Unix, Gnome and KDE were developed using those libraries so most of Unix desktop applications you'll find today also used them. Microsoft and Apple have their own graphical libraries as well.
Many other libraries can be found for specific purposes but I advise you to test them and if possible read the code to make sure it won't fall into your own exceptions and with time you'll build a list of trusted libraries.
The Java Development Kit: The JDK is the standard distribution for Java development and it's like C standard library plus the STL. It already have all the algorithms, data structures, containers and everything you need to code whatever you like in Java. Newer versions of Java are much closer to C++ concepts such as templates and strong typing and should be used instead of older ones.
J[A-Z]+: Java programmers are a very weird community, they love acronyms. JAXP, JNI, J2EE, and so on for pages and pages. The good thing is that they're in a way supported standards so you'll probably find implementation to most operating systems. The most notable are the JavaBeans for enterprise development, Servlets, Struts and the Tag Library for web development and the messaging system. On the other hand, the mobile version (J2ME) and the lower level libraries are among the worse.
The Apache Project: In the last years the Apache foundation has been one of the greatest supporters of the Java programming language, creating the best tools for development, hosting, automation and deployment of Java programs. They covered virtually every spot of the enterprise development process for Java, twice. Though they didn't do much for standard libraries, you should always look in their site first when looking for tools and servers.
To program in Java you need to know much more of what libraries are available than any other programming language. There are so many options for each technology and so many avid supporters to all of them that it's difficult to know what really is good and what's just hype. Also Java lacks important projects for scientific development and the mathematical libraries are not as efficient as they should be, what is a big deal for bioinformatics.
Perl: The Perl standard library is embedded in the language since the beginning so one cannot tell whether something is a library or the syntax itself. The language as a whole is very well connected, logical and consistent but at the same time allowing any combination possible. This is why the Perl motto is: “There is more than one way to do it”. This is why Perl is so evil when the projects are medium or big.
CPAN: The central repository of Perl modules have everything. From good acclaimed standards such as Data::Dumper or Digest::MD5 but it's also where you'll find several modules doing exactly the same thing without any reference about which is the standard and which is not. I suggest you always look thoroughly in the CPAN website before installing and using the modules and if in doubt contact the author to understand his position about maintaining the module.
Much was said about Perl 6, a completely new language built from scratch with the input of the whole Perl community but little we know about when or even if it's really going to happen. While that doesn't happen I suggest you not to use Perl for programs with more than 100 lines and especially don't try to make it shorter by hacking Perl as it'll be even worse.