In looking at some recent blog posts, I started to wonder about the Nim community's attitude towards stdlib expansion in general. Do we take a python approach and pack Nim's stdlib with as many functions as possible, asking for PRs whenever a request is generated? Or do we want to push for "If something isn't in the stdlib just do it yourself"?
The only risks I see in contributing nearly any and everything to the stdlib is stdlib upkeep costs and situations where Nim users complain about the implementations of stdlib functions being somehow "bad" for their use case. That first risk is an investment imo, as a large stdlib will make us more attractive to the python dev community specifically, and can't hurt when attracting other users. The second risk is fine as well because I find the discussions that surround those queries to be very educational to all involved, as it exposes a bit how API design is done on Nim and can be a good window into understanding the rationale behind Nim's design.
I still like the "batteries included" idea. However, we have been burnt by that quite a bit, old libraries must be kept but are outdated, better solutions are available as Nimble packages...
The jury is still out on how to evolve the stdlib, see also https://github.com/nim-lang/RFCs/issues/371 for a recent discussion.
I think one of Go's main selling points is its strong stdlib.
Libraries and frameworks sort of work when you have a larger ecosystem but picking a webserver that will be abandoned when one has to move from Nim to a language that is in more demand is not nice.
Well I understand that the manpower working on Nim/stdlib is limited and putting more stuff into stdlib is just a burden.
I'm not a contributor to Nim's std so I can't properly estimate the maintenance burden of expanding, but from the user point of view, more tools readily available is better.
What I'm especially for, is the uniformity of the API. I think in the long run this is far more important than a sheer growing of available functionality.
In my view, a Standard Library should be an example of a proper and wide set of functions the users should expect the developers of third party libraries to implement. I really like how Rust treat this with traits and developed type system. For example, their containers have an Entry type which implements some handy functions for a view into a container. When I look at third party containers, I can usually make a pretty informed estimate of the quality and development state of the library just by seeing if it implements Entry. Some stuff that becomes auto-implemented when you follow the existing API induces the developers to keep in line which benefits the users immensely. What's more, all this functionality sits in one place and if I develop something new I know just what to copy. All of this in my mind looks more orderly and thus superior to a long list of overloading procs. I'd be glad to be proved wrong on this, but I think my concerns are generally valid regardless.
I actually like the idea of a strong and simple stdlib, with community packages supporting it. Defining strong and simple is the hard part though...
I don't think Nim needs to go to the is-odd level like JavaScript, but I think Nimble is moving in the right direction.
If anything, I think I can state that I would like to see every primitive and numeric data type to have an incredibly large suite of functions surrounding them. It's these building blocks that enable the community to make great things. Things like "Does Nim have stdlib YAML support?" should not be seen as a valid reason to not use Nim, as community packages will satisfy that.
Using Nimble packages create risks around their availability, security, forward and backward compatibility with Nim versions, proliferation of dependencies, and lifespan.
I still hope in the idea of vetting a set of "core" packages and optionally ship them together with the compiler.
Managing version as individual Nimble package doesn't mean you can't distribute it as a cohesive unit.
That's exactly what https://github.com/disruptek/dist does.
It's good when you have good and rich standard library that fits your use cases well.
The problem is, good means different things for different people and use cases.
And while I like Nim, I don't always like the way its std is written. I think it would be hard to satisfy all the use cases, so I think it would be better for nim to have minimal std.