> the standard library is very large
Yes, but the APIs design is very far from what you'd expect from a typical dynamic language. When you tell a typical Python/Ruby/Perl/PHP/Lua programmer that you can't just call `length` on anything collection-like, but need instead to call `string-length`, `vector-length`, `hash-size`, etc. - they remain unconconvinced, to say the least. The higher-order abstractions, like collections, sequences, streams are there, but rarely used (if at all) in the stdlib itself and you won't encounter them in tutorials. Then, some APIs are incomplete, like the date and time support, even with relevant SRFI.
The language is expressive enough, fortunately, for people to build their own stdlib replacements, like Alexis King's collections-lib (and related), gregor library for dates, or rackjure lib for thread-first/-last macros. But you need to know about them, otherwise you're going to invent lots and lots (because it's so easy) of your own conveniences and will do it poorly for the most part, while also losing time.
Well, it's still orders of magnitude better situation than with Pharo, which was also released in 7.0 version recently. In Racket, all of the stdlib is covered with extensive documentation comparable (sometimes favorably) with Python docs. Most additional packages are also documented the same way, it's great. As long as you can get past the base distribution lack of conveniences (or sometimes features), though, Racket is one of the most beautiful languages and language ecosystems I've encountered.
I did two little projects in Racket, recently: one was using Slideshow for making slides for a presentation, the other was using plot for making some graphs. In Slideshow, I ended up writing some 200 loc for it to display syntax-highlighted, colored code of non-Racket languages, which would be free in any JS-based presentation framework. After that it was a relatively smooth sailing, although the outline-generating API is definitely overcomplicated. In the other case, I had to parse a bit of text and then do a lot of computation on dates and times. Very frustrating experience initially, until I found gregor lib and megaparsack. The 5+ other solutions (for parsing) were too heavy-weight and inconvenient to use and I was just going to fall back on regexes (which are also not very convenient to use), but fortunately I found Alexi's megaparsack lib, which is almost as good as PyParsing.
Anyway - lots of rough edges in the stdlib, a lot of cruft - but at least well-documented - and some interesting libs you can use to bring it up to modern standards. And the module system makes using these packages painless - even if they rewire lots of stdlib - which is something Smalltalk/Pharo guys are yet to achieve.