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-
d-announce wrote:

Could you please back up that assertion a little bit? From all I
see,
standard libraries of most languages grow very fast with each
release.
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 unicode, etc.

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.
Or Anaconda.

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 alternative?

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
TOML.

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.


Andrei

Reply via email to