Results: https://gist.github.com/GULPF/6d49e74af9992f8fc65476a9264488a0
Some observations:
Note: I based the list of stdlib modules on this listing, which includes some modules that are not listed on the main documentation page.
@GULPF
That's very interesting, actually! I never thought I'm SO mainstream using so many macros. :D
I am against reducing standard library. Many developers find C++ useless without boost, python has huge stdlib and its main advantage of python. Dead code elimination on Nim makes less of a pain to import large libraries.
Installation of third party libraries is always a pain. Corporate firewalls, proxies and antiviruses makes it impossible to use package managers like nimble.
I am against reducing standard library.
Fully agreed! To the contrary, I would prefer to expand it.
I agree that a big standard library is useful, and that there are areas that could be expanded (e.g I think the stdlib should include a heap implementation). But it only works if there are contributors interested in maintaining the modules. For some of the current modules, that's not the case. Take a look at xmldom and xmldomparser. They are used in 0.2% and 0.5% of projects, they haven't been touched in a long time (xmldomparser hasn't had a commit in over 2 years), they use outdated naming conventions and so on. Modules like those can easily be cut from the standard library.
Another advantage of Nimble packages is that they are updated independently. Updating the stdlib is an all-or-nothing kind of thing. Either you deal with all the breaking changes in the compiler and stdlib at once, or you don't update at all. This usually means that stdlib modules are very limited in what kind of breaking changes can be done - this is why we have parseopt/parseopt2, re/nre and so on. Because of this, bad design choices in standard libraries has a tendency to stay around for ever (examples of this can be found in any popular language).
Adding a short opinion regarding what should be in the standard library for v1.0. Keep in mind my background is mostly python, however, I'm still a newb with Nim.
One of Python's selling points is the large standard library that is distributed. But one of it's flaws, however, is that it only has two levels of libraries:
That means if needed library is not in standard, it is very non-obvious which competing library is a good one. One has to hunt-around the similar libraries and try to get a "general impression" and hope you are right. Looking at repo update traffic helps, etc.
My recommendation for nim:
...and, something not seen elsewhere, a possible third category...
Just ideas...
BTW, I've toyed with the idea of arbitrarily creating the nimble website; as I would have found it useful myself. But I don't want to step on anyone's toes.
Of course data from real applications is still scarce. For example, logging and unittest should rank very high in reality.
Anyone demanding an all-batteries-included-stdlib for Nim 1.0 release should consider the enormous amount effort needed for reaching and maintaining production-ready quality. Below are some examples. I don't see why Nim could be the exception.
Boost:
Python:
Java:
Well sadly these plans look more and more problematic to me.
Nim - Core
Everything koch boot -d:release and koch tools needs. Nothing more, nothing less.
Problems:
Nim - Standard
Nim - the full experience (TM)
And then on top of having 3 different ways to install Nim (zip, choosenim, build from source; which is at least one too many) we offer them 3 separate "distributions" that all have to be tested and maintained (!). And what problem does it even solve? To have some philosophically pleasing "small core"? To see if a module is essential for porting, remove it and see if "koch boot" still works...
Ways to install Nim have nothing to do with the std lib quality/size trade-off. The end user should only be offered the Nim standard distribution. Nim core should be interesting only for people writing alternative compilers or having a non-standard OS like FreeRTOS. "Full experience distros" should be unofficial and their maintenance out-of-scope for Nim core devs. Every layer should build upon the lower layer, therefore testing and maintenance should become easier, not harder.
If you integrate networking stack etc. to the compiler and continuously bootstrap the compiler with stdlib novelties and vice versa, Nim would not be just a programming language, it would become a programming environment (more like .NET than C). Nothing wrong with that - I would use Nim anyway - but making an alternative implementation would then become very hard.
These two things are equals important, and I think they need different groups of people to manage them.
Sorry if I doesn't make myself clear, English is not my native language.
quick correction regarding my earlier post: apparently there is already one website for nimble packages: https://nimble.directory/
I just happened to come across it via a random google query. I don't see it referenced on nim-lang.org. Or even on the packages repo. It is on the wiki; though not under the packages part.
It appears to be coming from https://github.com/FedericoCeratto/nim-package-directory
Is this an official source of things? If so, I'll create PRs for both https://github.com/nim-lang/website and https://github.com/nim-lang/packages to add references. If not official, I'll just update the wiki perhaps.
It would contain less code, therefore less bugs
It would also be less useful.
Nim language reference would be smaller and therefore compiler implementation easier
The language is not its stdlib.
It would be easier to develop a test suite that signals the production-readiness of Nim
We have a good test suite.
It would strengthen Nim's status as a systems programming language
This sentence lacks substance.
There would be more time to develop new features instead of maintaining legacy code
Depends on how we do it. "The stdlib modules that nobody uses and thus get no bug reports and receive no commits" are not exactly slowing down Nim's development...
I can see the value of cleaning things up, don't get me wrong, and it's important for version 1 but let's be realistic, it won't make developing a WebAssembly backend any easier.
Is this an official source of things? If so, I'll create PRs for both https://github.com/nim-lang/website and https://github.com/nim-lang/packages to add references. If not official, I'll just update the wiki perhaps.
We want to make it official.