A lot of language popularity indexes are based on things like number of repos in github, number of pull requests to number of repos, forks etc.
Languages like Javascript/Rust/Go have lots of small libraries which probably impacts their popularity ranking in those popularity indexes.
With that in mind maybe its better to:
I'm not saying we should go the way Javascript with things like left pad but if the main Nim Lang repo is smaller everything would become a bit more manageable and it would be easier to get to V1.
I was thinking about this more from a manageability and scaling perspective, if stdlib modules are grouped logically and maintained in separate repos, more collaborators could be brought onboard over time to own and maintain them without having to be given full access to the main repository.
You could have git submodules in the main repo and still keep it all together or just use nimble itself, but things would be more distributed and move independently.
The alternative is the current method - add more core devs. to the main repo to accept PRs. They would need to play to their strengths and self-regulate. The bar to get accepted is and probably should be very high though.
@juancarlospaco Maybe I wasn't explicit enough but the intention of my original post is to be somewhere in between the current Nim standard library monolith and the other extreme of javascript which has minimal stdlib.
In no way did I intend to promote the javascript package manager.
Your suggestions are valid and worthwhile however they are not mutually exclusive to what I am suggesting which is to make the Nim stdlib easier to maintain by cutting out the any marginal stuff that can live in its own repo. The benefits are Nim core is easier to maintain given the resources available and also it can help boost the number of packages available.
@shashlick some good suggestions here.
IMO, you achieve exactly zero by moving existing code from one location to another location.
As mentioned by @honhon you achieve at least one thing: an increase in the popularity metrics.
I for one think a lot more tools in the Nim repo should be moved into separate repos. This was done for nimsuggest, but then Araq moved it back due to its dependency on the compiler.
This is currently the state of c2nim. While it's challenging to keep these projects separate it has multiple benefits:
I agree @dom96
Take for instance ehem, Python, Python does not include database wrappers or consolidated database api in its standard library.
Maybe all Math libraries except Math, and Random should be moved out of stdlib into a separate consolidated enhanced Math library.
It would be interesting to get import statement stats on all libraries in Nimble to see what people are actually using and prune out the low hanging fruit.
So lets say for a moment there was a smaller standard library. There could also be some boost packages for different domains which come with a bunch of additional packaged up libraries.
For example you would have a set up like this on github:
Automated CI testing could be set up across these different boost packages when updates were made to the core.
That way people interested in specific domains could spend more time on the domains they were interested in and they could contribute to those domains. You could set up communities around each of those domains.
It would be interesting to get import statement stats on all libraries in Nimble to see what people are actually using and prune out the low hanging fruit.
GitHub stars are far from an accurate measure of popularity and, even less, quality. (Correlating install counts and other statistics shows that). If anything, stars measure virality on certain social networks and marketing.
Also, "When a measure becomes a target, it ceases to be a good measure." [1]
"When a measure becomes a target, it ceases to be a good measure." is very mild statement. In practice it is much worse: as soon as people find out that you intentionally forged statistics they will hate you. And you can say they were wrong about you either.
this "Tactics" smells...
Optimizing for benchmarks is also intentionally forging statistics and we already do that in the community.
Tell me cdome, do people hate hate the people that have been intentionally forging statics for these languages https://github.com/frol/completely-unscientific-benchmarks, https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/knucleotide.html, or these frameworks https://www.techempower.com/benchmarks/previews/round16/
The technology game is a game.