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

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

Let's write a D, phobos.
Then we drop all the features and use a BetterC mode.
Then we write all modules against betterC mode.

On Sunday, 18 December 2016 at 11:06:58 UTC, Temtaime wrote:
> Let's write a D, phobos.
> Then we drop all the features and use a BetterC mode.
> Then we write all modules against betterC mode.

Sounds like a plan! --Ilya

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!

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.

As for Andrei and Walter - I think you need to see why people (talented people!) want to side walk the phobos & druntime normal contribution routes. Something clearly is wrong there!

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

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

On Sunday, 18 December 2016 at 15:01:55 UTC, Ilya Yaroshenko wrote:
> On Sunday, 18 December 2016 at 14:37:55 UTC, Radu wrote:
>> [...]
>
> Maybe I will be able to propose them on DConf.
>
>> [...]
>
> 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

I get point 2, but I should be able to use your new modules without giving up druntime/phobos, right?. They should not be mutual exclusive!

On Sunday, 18 December 2016 at 15:20:48 UTC, Radu wrote:
>
> I get point 2, but I should be able to use your new modules without giving up druntime/phobos, right?. They should not be mutual exclusive!

I think that being able to use them the same as any other C library should be sufficient.

On Sunday, 18 December 2016 at 15:20:48 UTC, Radu wrote:
>> 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
>
> I get point 2, but I should be able to use your new modules without giving up druntime/phobos, right?. They should not be mutual exclusive!

Yes, you are able to use any Mir libs with Phobos/DRuntime --Ilya

On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote:
> We already have better `cpuid` and better `random` packages.

Great! Please PR them for Phobos.


> 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)

Propose them for Phobos!


> Andrei and probably 90% of existing D users don't want Phobos to move this
> direction.

I don't understand that point. What 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.

The language evolves over time, and the standard library must, too. It happens with every language.


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

Not sure what you mean. Algorithms in Phobos are not dependent on system idiosyncracies.


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

I've done a fair amount of work to remove such things. Clearly more can and should be done.

Generally, we do have a goal of making Phobos entirely "pay as you go" instead of being so interconnected (which is what betterC is really all about). We can definitely use help in improving that and helping it along.