A betterC modular standard library?

[Ilya Yaroshenko via Digitalmars-d]

On Sunday, 18 December 2016 at 14:37:55 UTC, Radu wrote:
> On Sunday, 18 December 2016 at 09:26:09 UTC, 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.
>>
>> 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.
>>
>> 2. We can not do hot fixes in Phobos without compiling and 
>> deploying patched libphobos. Mir's DUB package are much more 
>> flexible.
>>
>> 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.
>>
>> 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.
>>
>> [1] https://github.com/libmir/
>> * - separate github/DUB libraries with clear dependencies.
>>
>> Best regards,
>> Ilya
>
> I hope this doesn't turn into a new Tango vs. Phobos war.
>
> If you have ideas on how to improve things without messing the 
> entire community with ego wars and such, then it sounds good. 
> Otherwise thumbs down!

Maybe I will be able to propose them on DConf.

> The first sign of faith will be that your modules will always 
> work with druntime and phobos - i.e. you wont require a special 
> runtime for your stuff to work.

Yes/No in the same time.

1. It would be always possible to use Mir and Phobos together, 
100% guarantee. Furthermore, some Mir libraries are going to be 
infrastructure for _all_, not only for D. For example Mir GLAS 
will target the Julia language after D.

2. In the same time many thing is not possible to create with 
Phobos/Druntime. The simplest example is numeric libraries. I can 
create a multithread GLAS with core.thread, but if I do so GLAS 
will never be accepted as default BLAS implementation for Julia. 
So, i need to create my own low level thread library. Intel MKL, 
OpenBLAS have their own thread management: this is common 
practice.

Cheers,
Ilya