There's actually a surprising amount available in the stdlib for your typical web project. By way of example, I'd always hated how in Ruby each API wrapper gem would make their own decision on which HTTP client they used, so you could end up pulling in 3 or 4 separate libraries just to make HTTP calls to a 3rd party API. People may disagree but I think this is (was?) largely due to Ruby's Net:HTTP feeling janky to use, at least compared to Faraday and the like. Here, the HTTP modules within the standard library feel right, and I've not needed to reach out for all that much from the ecosystem.

But as a simple example I accept that API calls to third party services is low hanging fruit so in terms of finding drivers for lower level protocols I've not had an issue that I'd class as a blocker. There are times where I've had to extend libraries or write a parser for this-and-that (e.g. PostGIS and Paseto, both of which were unused this time round) but I find I need to do this less and less as time goes on.

You do need to reach into the forums or gitter on rare occasions but I can count on one hand the number of times I've needed to, and it's typically because I was trying to do something unusual and quite low-level on the HTTP stack - as in something I've never had to do in a non-Crystal project, such as sending a specific packet. I've always found help there too and people are happy to engage.

It's obviously far smaller, but I've had luck so far with everything I need being available. What I've seen, mostly Postgres, Redis, and XML/HTML parsing, have also worked flawlessly so far.

Having performance improvements of 100x in real-world scenarios is just astonishing. Ruby is still my go-to, especially because debugging and console support are so much better. But everything that gives me time to think gets reimplemented.

["crystal lang" <question>] usually works for google.