On Monday, 19 December 2016 at 01:33:42 UTC, Mike wrote:
> On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote:
>
>> Who is interested in betterC _modular_* standard library?
>
> What exactly do you mean by "betterC"?  As far as I know, the `-betterC` switch just removes ModuleInfo generation.

Because -betterC was not implemented yet.

> Do you actually mean, a standard library that has fewer dependencies on druntime features?

I mean this too

Ilya

On Monday, 19 December 2016 at 01:52:21 UTC, Andrei Alexandrescu wrote:
> On 12/18/16 7:31 PM, Seb wrote:
>> tl:dr: Phobos is very bloated.
>
> How does the D standard library compare in size with some other languages (C++, Rust, Go, Java, Python)?

C++ and Rust are the best from this list in terms of low level programming. They have smaller libraries comparing with D.

Go, Java, Python --- If I need a language like them I will you them, not D.

Go - awesome GC, commercially supported, easy to write your own libs
Java - awesome GC, commercially supported, Scala(!!!)
Python - awesome scripting, commercially supported

D - ??? awesome what ? What do we have better then Scala?

Performance? NO.
BRandomAccessRanges makes our performance less then C/C++.

Clean and clever API in standard library? NO.
We are placing our Range API whenever possible including RNGs. We have not a language standard for I/O. Half of Phobos is outdated to language standards.

Best generics? NO.
Scala is more powerful.

----------
What do we have awesome? Where D is the best?
----------
D is awesome for low-level system libraries in betterC mode.
(and small text processing routines)
This will make D great in other fields.
----------

>> Let's do something about it!
>
> I've said this several times, and it bears repeating. We want to make D entirely pay-as-you go, and offer full support to anyone working on it. The best "something" anyone can do about it is do good engineering work in the D mainline.

National D Foundation Party.

> That will automatically benefit all users of the D language, instead of balkanizing the community.

...

> Granted, the lure of the clean slate is strong, and more care is needed to mind backwards compatibility, but that's where the real impact is.
>
>
> Andrei

How Mir projects breaks backward compatibility ?

How proposed direction breaks backward compatibility?

Lets use other prefix for the new libraries. Mir uses `mir.` And allow Phobos to be a sandbox for C++ as it is now.

Ilya

On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei Alexandrescu wrote:
> On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote:
>> On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote:
>>> 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.
>>
>> cpuid is used in Mir GLAS and it should be a betterC library.
>
> It's this kind of imaginary dialog that I don't quite grok:
>
> Ilya Yaroshenko: "I can't use druntime's cpuid so I defined my own."
>
> Andrei Alexandrescu: "OK, so what's different?"
>
> IY: "Mine has a few engineering improvements."
>
> AA: "Cool, why don't you merge them into core.cpuid?"
>
> IY: "Well mine doesn't have a shared static constructor, so it doesn't need a runtime to automatically call that library initialization function. User need to explicitly call an init function before using it."
>
> AA: "I understand. Great, so how about this - we add your code to core.cpuid_v2 to druntime. Then we make all in core.cpuid to forward to it so there's no duplication. It all works out!"
>
> IY: "No, I don't want to do that. It's still in druntime and I don't want druntime. I want betterC."
>
> AA: "But it will be compilable with betterC and we can add unittests to make that happen. YOU HAVE MY SUPPORT. Let's do it."
>
> IY: "No, I want to change it often. The deployment schedule of druntime is too slow."
>
> AA: "How often do you need to change it? Is it that unstable?"
>
> IY: "Um, not too often."
>
> AA: "Then what is the matter? Are you worried about the IP of the engineering improvements you are making? Are you licensing this differently?"
>
> IY: "No, it's for the most part similar to core.cpuid and the license will be also Boost."
>
> AA: "Then what is the matter? Do you want me to wait until you release a stable mir.cpuid and copy it over with credit, per the Boost license, to core.cpuid_v2?"
>
> IY: "..."
>
> It's this kind of stuff I need to have a better understanding of. Some technical arguments are meaningful, some others point to problems with obvious solutions that are somehow shunned, and yet others are like a hidden Markov model - I see the effects, but I don't see the causes.
>
>
> Andrei

I think, the reason of misunderstanding is different skills in a subject. And even different subjects. Some experts are compilers developers, some are library developers. They all in different subject. In c++ community there is a group of compiler developers experts who desides, how to implement this or that feature, and the ability of implementation. They know how to develop compilers. It doesn't mean they are more clever than library developers, just different skills. And when Andrei asking to explain the reason of some proposal, he waits arguments in _terminology_ of comliler developer. _terminology_ understanding (in wide) means _experience_ (compiler developing in this case). If no experience in the subject, there is a way to get it, and the other way to ask a recommendation of experienced colleague.

On Monday, 19 December 2016 at 05:22:10 UTC, Ilya Yaroshenko wrote:
>> What exactly do you mean by "betterC"?  As far as I know, the `-betterC` switch just removes ModuleInfo generation.
>
> Because -betterC was not implemented yet.

I'm curious to know what a complete implementation entails.

>> Do you actually mean, a standard library that has fewer dependencies on druntime features?
>
> I mean this too

I've been wanting to decouple from druntime since I started learning D in late 2013, though probably for different reasons than yours.  There have been two recent posts [1] [2] wanting to do the same thing, and now your post envisioning a more modular druntime-less phobos.

[1] - https://forum.dlang.org/post/drqdrobcoaanenocycgp@forum.dlang.org
[2] - https://forum.dlang.org/post/tmofjecvnqdthvetezfp@forum.dlang.org

It's encouraging to see this trend.  I am interested in seeing D become more modular and pay-as-you-go, though I'd prefer to see changes in the compiler and druntime (e.g. [3] [4] [5]) before phobos.

[3] - http://forum.dlang.org/post/mr71kt$2rgi$1@digitalmars.com
[4] - http://forum.dlang.org/post/eiwalbqlbkipdrmsrfoh@forum.dlang.org
[5] - https://issues.dlang.org/show_bug.cgi?id=11666

Mike

On Monday, 19 December 2016 at 05:59:07 UTC, Ilya Yaroshenko wrote:
> D - ??? awesome what ? What do we have better then Scala?
>
> Performance? NO.
> BRandomAccessRanges makes our performance less then C/C++.
>
> Clean and clever API in standard library? NO.
> We are placing our Range API whenever possible including RNGs. We have not a language standard for I/O. Half of Phobos is outdated to language standards.
>
> Best generics? NO.
> Scala is more powerful.
>
> ----------
> What do we have awesome? Where D is the best?
> ----------
> D is awesome for low-level system libraries in betterC mode.
> (and small text processing routines)
> This will make D great in other fields.

while i mostly use D as a awesome high level language (with mediocre libs, and an inconsistent stdlib) i also think that D has an edge when it comes to building fast system level tools that used to be written in c: microservices, datatabases etc.
however for that, as ilya mentioned it needs to be super user friendly to compile down a single static object/binary with no dependencies and a clear line on when phobos can/should/must be used and when not (e.g. create a view on phobos documentation that only shows things that work without druntime. add some official docs on how to use it)

people turn to C to extend their language of choice because they need speed in a very narrow area. if that becomes as easy (or even easier, since there is dub!) as with C it would be a huge win for D, because people would start to extend their stuff with D. No other language is in a such good position as D, from what i see not that much needs to be done to make that work.
i see a huge opportunity there

On Sunday, 18 December 2016 at 18:02:58 UTC, Ilya Yaroshenko wrote:
>
> Thank you for the answer (it is hard to understand me because English and other reasons),
>
> Ilya

It was difficult to understand your vision until this post, now I think I grasp it.

Let me try to summarize what I've understood:

D as it stands, is not suitable for writing low level libraries as well as large scale software development because of compiler dependence of compiled code.

Examples:
If you have two software teams, and team A's software dependent on compiler X (e.g requires newer feature, requires bug/regression fix, etc) and team B's software depends on compiler Y to meet performance requirements, they get stuck.

Also you want to create a low level library than can be easily distributed and linked from other languages (e.g. GLAS) extern (C) is the only viable option, but that can still lock in the D compiler used if you depend on phobos/druntime.


So the proposal is to make binary compatibility possible in the near future by implementing "betterC" which provides a bare-bones language and removes the greatest sources of incompatibilities.

Once this is done a community can form around it and create completely modular libraries. These can be used by all D and non-D users alike without compatibility problems.


Since this is all predicated on "betterC", which isn't implemented. I think it is imperative to create a full specification.

I look forward to seeing where this initiative goes.

P.S.: I think Ilya writes "evaluates" where he means "evolves"

On Monday, 19 December 2016 at 18:04:14 UTC, safety0ff wrote:
> On Sunday, 18 December 2016 at 18:02:58 UTC, Ilya Yaroshenko wrote:
>>
>> Thank you for the answer (it is hard to understand me because English and other reasons),
>>
>> Ilya
>
> It was difficult to understand your vision until this post, now I think I grasp it.
>
> Let me try to summarize what I've understood:
> [...]

Yes, thank you for the clarification!

> P.S.: I think Ilya writes "evaluates" where he means "evolves"

Oh, yes! I mean "evolves"!

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:

If I understand correctly, the only reaon not to disable the runtime instead of going betterC (what I call runtime-free vs runtime-less) is because Phobos and druntime aren't ported to every platform you need, but the libC is.

That it calling for the question: "Isn't porting Phobos and druntime to those new platforms your clients need less work?"

Maybe they only need ARM and x86-64, the effort should be minimal then? And with the runtime disabled, things like the GC just need to link, not actually work :)
Tha makes porting a bit simpler.

Things like std.algorithm, std.range, traits etc... took many man-years to do and can work as is.
core.cpuid can work with little modifications.

I'm not saying you can use a lot of Phobos and druntime without using the runtime, because currently you can't.
But think about it: when not linking the runtime, there isn't even a way to call "emplace" or "destroy", dynamic casts won't work, etc.

In the future more and more things will work without the runtime, exceptions, class creation and then you'll don't have to maintain a stdlib.

Please reconsider reconsidering.

On Monday, 19 December 2016 at 19:31:24 UTC, Guillaume Piolat wrote:
> On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote:
>> [...]
>
> If I understand correctly, the only reaon not to disable the runtime instead of going betterC (what I call runtime-free vs runtime-less) is because Phobos and druntime aren't ported to every platform you need, but the libC is.

No,
1. DRuntime has not fixed API
2. It has not backward binary compatibility
3. It has not cross-compiler binary compatibility.

So, it can not be used.

On Monday, 19 December 2016 at 19:42:42 UTC, Ilya Yaroshenko wrote:
> No,
> 1. DRuntime has not fixed API

Can't you static link with it? If you static link with it, your client don't deal with DRuntime.


> 2. It has not backward binary compatibility

Ditto. If you static link with it, your client don't deal with binary compatibility.


> 3. It has not cross-compiler binary compatibility.

Mandate that every D code in the project is built with the same compiler, which is realistic.