Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

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