A betterC modular standard library?

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/16 4:26 AM, Ilya Yaroshenko wrote:
> Hi,
>
> Who is interested in betterC _modular_* standard library?
> I am planing to make libmir org a community for it.
> Thought and concerns?
>
> We already have better `cpuid` and better `random` packages. The betterC
> std.range and std.algorithm analogs would be released with new ndslice
> implementation. Mir's algorithm would be faster then Phobos and will
> generate less template bloat. Then lightweight threads, multithread
> GLAS, matrix inversion. Fastest I/O and http2 ...
>
> (they all are betterC modular libraries)
>
> Andrei and probably 90% of existing D users don't want Phobos to move
> this direction.

Please do not misconstrue what I said.

You have my support to improve the state of affairs with the D core 
runtime and standard library, and have had it from day one.

With regard to new functionality that supplants existing pieces such as 
cpuid_v2 or random_v2, definitely. We can and should add that and many 
other great things to phobos. Go for it.

With regard to avoiding to link druntime, we should build the argument 
better. Is all of druntime bad, or just parts of it? E.g. if something 
does not link the GC but does use vtables, is it good/bad, and to what 
extent? These issues are not entirely clear to me and it would be great 
if you explained them better. I definitely need to be better educated on 
this. What I do know is making "don't use druntime" a goal in and of 
itself is not the most useful way to frame the problem.

With regard to changes that break the entire fabric of Phobos (such as: 
we must eliminate random-access ranges), this is definitely more like 
simple survival rather than things I want.

With regard to properly attributing credit for good work, I believe this 
is important and I commit to do anything reasonable for making it happen.

I kindly advise you to better understand what you are trying to do, and 
how to do it to maximize impact. It seems you are not entirely clear on 
what you want to do and what the best route is, as shown by you retiring 
your std.experimental.ndslice work after you've had full freedom on what 
should go in it.

> In other hand I need a commercial attractive D infrastructure for large
> and heavy system projects. There is no commercial perspective for me to
> contribute to Phobos because:
>
> 1. Phobos version depends on compiler version. Delay with LDC release is
> too large. It should / can be one day.

Then a good way to help this is improve the LDC lag.

> 2. We can not do hot fixes in Phobos without compiling and deploying
> patched libphobos. Mir's DUB package are much more flexible.

The reverse of that is less stability. The good part about merging your 
work in Phobos is you maximize impact and visibility.

These seem to me artificial arguments. Yes, being preoccupied over quick 
deployment may make sense in the initial stages when there's no 
stability and the design may take any direction. That should get less 
necessary once some abstractions are in place.

Organizations that are interested in patching minute fixes may build 
their own standard library (and sometimes compiler). This is routinely 
the case with C++ at Facebook, Google, and in all likelihood other 
large-scale tech shops. It would be tenuous to argue that this should be 
the default way to go about things for everyone. I don't understand why 
you consider it an essential matter.

> 3. Dependencies should be clear. Modularity is a proper way for large
> std library. In phobos everything integrated with everything. DRuntime
> -> Phobos abstraction is weird for betterC because system modules can
> depends universal algorithms, but universal algorithm are more portable
> if they have not system dependencies.

I read this three times and cannot understand it. At any rate: DIP 1005, 
which is partially motivated by our discussions, should allow us to make 
dependencies as simple and clean as function-level.

> 4. Phobos does not provide and will not provide betterC guaranties. If
> something works for betterC mode now it may not work in the future release.

Yes, we can definitely improve this.

We (the Foundation) are all for making things better for achieving the 
things you want to achieve. At this point D needs unity and rallying 
under a shared vision, not balkanization in several special interest 
groups. There are so many great things you can do starting literally 
today to make things better for everybody using D, and why in the world 
would anyone want to stop you. I strongly believe your participation to 
the Standard D language and library will be vastly better for you 
personally and professionally.


Andrei