> That's a reasonable concern for sure. Still, until the cloud providers find > Nim important enough to ship their own SDKs, this is a MAJOR use case in the > real world, and will be a real impediment in to adoption in a lot of tech > companies, if it's not easy to find something that works well and is clearly > around for long-term support. > > Perhaps that suggests having another "ring" of modules that aren't shipped > with Nim, but are officially maintained via the foundation.
IME a much larger barrier to Nim's adoption in tech companies is the lack of available talent. This seems like putting the cart before the horse - tech companies aren't eager to gamble on new technologies if they know they can't hire developers to leverage them. I agree that Nim's ecosystem is important, but Nim needs to attract more developers to it. I think that developer experience (tooling, error messages, documentation) and marketing should get attention before core developers begin focusing on cloud native libraries. My preference would also be that if Nim were to ever offer "officially supported" cloud native libraries, that they are kept separate from the standard library and would be an optional part of a distribution, if they are even bundled with it and not just offered up as separate nimble packages / whatever.
