Why Phobos is cool

[Petar]

On Thursday, 25 June 2020 at 16:25:01 UTC, Andrei Alexandrescu 
wrote:
> On 6/25/20 10:27 AM, Petar Kirov [ZombineDev] wrote:
>> The way I see things is that we as a community need to focus 
>> on a vetted, well shaped collection of libraries.
>> We need to have process where third-party libraries are able 
>> to gain broader support and join dlang-community. Also we need 
>> dlang-community to have a healthy number of people who 
>> actually maintain the code.
>> We need the leadership to realize that investing just in dmd, 
>> druntime and phobos is necessary, but very insufficient.
>> W&A need to stop pretending that Dub doesn't exist. I feel 
>> that unless we embrace using code.dlang.org as method of 
>> distribution of everything that's currently part of the 
>> compiler archive, Dub's limitations will never be addressed 
>> and from that the broader community will suffer.
>
> (By the way just to clarify "A" in "W&A" would stand for Atila. 
> I'm commenting as just one in the community.)

Hi Andrei, well, I meant Walter and you during 2015-2019, though 
just to be clear, I neither wish, nor it was my intension to turn 
this discussion into a personal attack. My goal is to stress how 
important it is to focus on helping the community grow and scale 
in a healthy way. Focusing just on the language spec and 
implementation is missing the bigger picture, IMO. But since you 
decided to address specifically this point, I'll try to elaborate 
more:

I don't recall you or Walter getting involved with the 
development of dub or the dub-registry in any significant manner. 
I remember that you criticized the addition of SDLang as an 
alternative to JSON package description format, but that's it.

I feel there is a very big disconnect between you and the 
community. One on hand, I think that Dub and code.dlang.org are 
one of the biggest assets of the community. On the other hand, it 
seems to me that you're not interested in Dub at all. It's just 
another community project that "they"'re free to do whatever they 
want it.
For example, my impression (though I'd be happy to be wrong), is 
that you have never actually tried using Dub for any project of 
significant size, or such depending on a significant proportion 
of code that you don't maintain. On the other side, take as an 
example any company that needs to bring a D web project quickly 
to market. The first thing they'll likely reach for is dub + 
vibe-d + mysql-native + some js frontend framework - basically 
100% third-party code for that team. Since (as far as I'm aware) 
you haven't invested much time in projects like this, I'd guess 
that it would be hard for you to fully appreciate the necessity, 
challenges, and benefits of using a package manager like Dub. 
Which is why, to me it seems that Dub is not very high on your 
radar of important things to improve for to D succeed.

Different people having different priorities is absolutely normal 
but on the other hand, if hypothetically most people using D type 
`dub` in their terminal say 99% of their time compared to 1% for 
`dmd`, perhaps it's not unreasonable for the community to expect 
the leadership to take a Dub's issues in a proportional manner. 
Or at least the community would find it strange that the keywords 
code.dlang.org or Dub were not mentioned even once in the vision 
documents, e.g. https://wiki.dlang.org/Vision/2018H1. Yeah, 
"tooling" is mentioned, but honestly, that too unspecific to be 
actionable. On a related topic, "mobile" and "wasm" also not 
mentioned, which areas where D in theory could do very well, and 
its direct competitors are rapidly gaining market share.

> I'm a bit confused by this argument. So there is the compiler 
> and standard library, and then there's a community-supported 
> library, which includes a copy of the standard library under an 
> improved versioning schema. It's all legal and encouraged by 
> the generous licensing of the compiler and standard library, 
> both of which Walter and I fought hard in the past to obtain 
> and maintain.

Okay... though I don't see why you need to point this out.
Yes, getting dmd fully Boost-licensed was a great achievement, 
and I and the rest of community are all grateful for that, though 
we're currently discussing about Phobos. I have never used a 
language which doesn't have an open-source and 
permissively-licensed standard-library.

> Dub is the perfect place where community leadership can set the 
> tone and organized things as they need to without heavy-handed 
> intervention from above. Several people have criticized "the 
> leadership" for not doing things the way they wanted, so it 
> seems perplexing that leadership intervention is now asked for. 
> What's that nonsense with "pretending dub doesn't exist"? So 
> now they need to take ownership of the community-driven dub as 
> well? Isn't that a bit too much work for a handful of folks in 
> the best of times?
>
> Is money that's been asked for? We don't have enough to do 
> competitive hiring.

No, money is not what's been asked for. For me, the most 
straightforward way to look at things is as if the DLF doesn't 
exist and there's no money on the table in the first place. (Also 
funding can only reward future contritions, so in a sense, it's 
not fair to past contributions.) So what's left (in this way of 
looking at things) is just individuals motivated for whatever 
non-financial reasons (at least not direct ones) who are working 
to improve D. It follows that motivated, talented people who 
effectively collaborate and cooperate are the primary asset of 
the community. The job of the "community leadership" would then 
be to attract, cultivate, and **retain** community talent and 
endorse collaboration. If funding is not an asset, then the only 
remaining leverage is good community management.

> I don't think Bjarne or Herb have ever been accused of not 
> contributing to Boost (which they didn't), or asked to invest 
> in it. Boost has been a community-led effort which has had a 
> great influence on C++ development - with the participation of 
> volunteers, not the formal standards committee.

We can only compare D to C++ on technical merits. The size of 
their community is just in a very different scale to ours. For 
example, I work in a startup where everyone needs to wear many 
hats and handle a very diverse set of responsibilities. We have 
more projects than people. Previously, I've worked at Fortune Top 
10 software company with 20k+ employees. Needless to say, the 
scale is very different.

Instead, we should compare D to language communities developed in 
the past 10-15 years. I suggest you look around and see how each 
one is doing and what were the different steps they took. I can 
assure you that probably all of their leaders at some points have 
been accused of not paying enough attention to this or that thing 
important to some part of the community. That's normal. Leading a 
small community or organization is very different than leading a 
big one.

>>> Anyway, if we can, we try to stick with Phobos, as long as we 
>>> don't have a particular problem to solve that needs an 
>>> external library: recent example, Martin std.io or SumType 
>>> instead of std.variant ...
>> 
>> See, some of the problems in Phobos already have a good 
>> solution. The problem that we need to address is the trust.
>> The more high-quality and well-maintained libraries there are, 
>> the less cautious one would need to be before reaching to 
>> code.dlang.org.
>
> This is and will always be the case, and it's normal. A 
> standard library can't implement all special purpose libraries, 
> or even a significant fraction. A community-led library is a 
> great thing.

I agree completely. I was not trying to argue the other way 
around. I think Phobos needs to be slimmer (e.g. throw away curl, 
odbc and other nonsense).
For example, the only languages that have good built-in 
networking/HTTP libraries are the ones where this has been an 
explicit goal of the maintainers. Right now we don't have 
sufficient Phobos maintainers with the experience and interest in 
building a GUI framework, so nothing like this should even be 
attempted to be added to Phobos.

A library should only try to do what its maintainers are good at. 
In the case of Phobos that would be generic code like algorithms, 
ranges, allocators, containers, typecons, meta programming, 
process, path and file manipulation and basic IO. Everything else 
should be removed. I'm glad that https://dlang.org/phobos/std_xml 
is finally going away, as probably only Jonathan has real 
experience of building an XML library (hence dxml). Though that 
should have happened much sooner.