On 01/25/2016 11:26 AM, Russel Winder via Digitalmars-d-announce wrote:
On Mon, 2016-01-25 at 07:44 -0500, Andrei Alexandrescu via Digitalmars-
Could you please back up that assertion a little bit? From all I
standard libraries of most languages grow very fast with each
What are your facts? -- Andrei
Thanks for answering. I want to be convinced, and even if not, to gather
a more precise view.
The rhetoric is appreciated. What would be helpful here in addition to
it are a few links to evidence. You make lofty claims either of status
quo in different languages, or major shifts in strategy. They definitely
must have left a trail on the Internet. Any chance you'd substantiate
these specific claims below with evidence?
Go has a very small core, if you want anything else you write a library
and publish it. There is a massive and vibrant activity writing many
versions of stuff most of which wither by lack of use. Some, usually
one or two, in each domain thrive and become the de facto standard.
Everything depends on Git, Mercurial, Bazaar, and go get.
I look at https://golang.org/pkg/ and see a quite substantial standard
library, including things that some people argue shouldn't be part of a
standard library: archives and compression, cryptography, databases,
character encodings (including json and xml!), html templating, image
processing, suffix arrays (sic), logging, networking, regexp, testing,
tokenization. This list is _after_ I eliminated topics that I believe
should be part of a standard library, such as I/O, time, and even
I'd like to believe our stdlib covers a few areas that Go's doesn't, but
it is obvious to me Go's stdlib does (and reportedly very well) cover a
bunch of areas that we haven't set foot in yet. This doesn't quite align
quite at all with your view that Go is barebones and anyone who wants
anything builds it. From what I can tell, Go comes with plenty. (It is
of course relative; Go's stdlib may be small compared to externally
available libraries, owing to its popularity which the Go team deserves
due credit for.)
Rust threw out large tracts of what was in the original library,
including all concurrency and parallelism things, in favour of separate
crates. There is a massive and vibrant activity writing many versions
of stuff most of which wither by lack of use. Some, usually one or two,
in each domain thrive and become the de facto standard. Everything
depends on crates.io and Cargo.
Do you have reference to relevant material (core team blog posts, forum
discussions, articles) documenting the shift, boundaries, strategy,
motivation etc? A look at https://doc.rust-lang.org/std/ does support
your view that Rust's stdlib is minimal.
Python used to be batteries included, then they moved to having a core
to which only Python committers have access. There is a massive and
vibrant activity writing many versions of stuff most of which wither by
lack of use. Some, usually one or two, in each domain thrive and become
the de facto standard. Everything depends on PyPI, pip, and virtualenv.
Again, a few links to evidence supporting these statements would be
awesome. I am sorry for my being incult; I know of pip and used it a
couple of times but know nothing about all else. At the same time you'll
appreciate I can't just form an opinion on your authority.
There are many facts out there favouring distributed over centralized
for everything except the language itself and the runtime system, you
just have to look. Calling for an explicit, detailed catalogue is not a
way forward in this debate.
I am truly sorry but is appealing to your own authority a better
Dub needs to be front and centre, it represents D, not DMD, LDC, GDC,
druntime, Phobos. The core of a D distribution is Dub. In this D is
like Rust, Ceylon, Python, and JVM. And unlike Go. Go is too
libertarian in my view. Rust, Ceylon, Python, JVM have the right view
for me: centralized repository and management of distributed projects.
What Rust and Ceylon are missing that PyPI has is an highly opinionated
metric that helps you decide what is good and what is dross.
Of course Dub needs a better story around executables rather than
library packages. Go (go install) and Rust (Cargo build) do this so
much better. But then Go has a project structure model, and Rust uses
I do agree with Dub's importance. What's unclear to me is what are
reasonable criteria for including some given functionality within the
stdlib vs. an external one.