Does a new or emerging programming language really need practical libraries?

One trick is to build on a virtual machine or other platform that already has a bunch of libraries. This is why there are a lot of languages for the JVM and CLR. Objective C and C++ got all of the C libraries by being supersets of C.

Only if you want it to thrive. There are a number of interesting backwater languages that never get more than passing interest. Even the motivated developers that experiment with languages move on after a time if they can't do anything more than write Fib() with it.

Take the case of Lua. A compelling small language if ever there was one. It has many great things going for it: simple syntax, elegant grammar, small and efficient VM. Even after 15 years it has only gotten traction among game developers and as an embedded language. The obvious reason why is that their standard library is very small (for important reasons).

"If your language is well designed, then it would be easy to create a 'string' library or a 'date' library."

It may be easy to create such things with a new language, but you shouldn't have to.

I consider it good enough if established libraries can be linked to new languages (e.g. via C). That way, the unique features of the language can be more readily tested in existing tools. For example, I may have a program with a critical algorithm, that might be faster in a new language; if the language simply links to C, I can easily test that algorithm in the new language, without having to replace the rest of the program and the libraries it uses.

Note that I'm not saying it's bad for new languages to be capable of implementing something like a 'string' or 'date' in a simple way. In fact, such practical examples may help when learning the new language. It's just a question of whether or not that is mandatory before anything useful can be done with the new language.

By the time I've written a string library, a date library, a cgi library, sqlite bindings, a templating library, and a graphics library, I could have written my application in Blub.

A lot of these sorts of libraries contain an essential amount of cruft, either because they deal with crufty human things, or because they implement crufty standards.

If you're talking about more than trivial applications(examples: computational geometry, statistics, parsing and saving common formats) libraries become important as a means of offloading effort. They can be abused, for sure, and by being overly general purpose they can often cause no end of trouble, but using a few good libraries appropriate to the domain may result in 1000x less time to get productive results, even if the language sucks. So you've just gotta have libraries. The problem a lot of new languages face is that they aren't different enough to necessitate building out a new set of libraries. Bindings to C are an ugly 80% solution, good enough for most cases, and they have the nasty result of making C even more all-consuming as the source of all library code.

haXe and Factor are both good examples of languages that have a basis with which to grow their libraries. haXe is getting uptake from a variety of angles but the emphasis is clear the everyone involved wants to minimize the costs of multiple-language incompatibilities, and that is resulting in powerful libraries across multiple domains. I don't know the details of Factor's growth, but I suspect that it is doing so on its strengths as a "next-gen" concatenation language in a field with little comparable competitors. Both languages have C bindings available, but haXe in particular has strong reasons to create native libraries.

It doesn't matter how well your language is designed - it is not easy to write libraries from scratch for regular expressions, HTTP serving, or emitting json. All things that are pretty handy for hacking together a website.