On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner wrote:
> On Saturday, 4 March 2017 at 15:35:13 UTC, Ilya Yaroshenko wrote:
>> [...]
>>>
>>> my 1 cent: we should stop trying to convert C++ users.
>>
>> Please, do no push devs to do not do something. There are two directions: betterC and DRuntime.
>
> I've tried to follow the "betterC" discussion, but so far a precise specification of what betterC is supposed to be eluded me. What I got was that you seem to be judging druntime to be too heavyweight and want something more lightweight, but I was never clear on what exactly.
>
>> I believe in betterC and  betterC target is C/C++ industry. Old D users are happy with DRuntime and growing Phobos.
>
> Please don't throw all "old D users" in the same category, generalizations like that only alienate. On a related note: What I believe in is that D's community can't take another rift like Phobos/Tango, D1/D2, so I've been very skeptical regarding the value of betterC.

I don't care about existing D users. Sorry about that. In the same time I do not see any problem with betterC for existing D users. Any betterC library can be used with Druntime like either a common C library or generic D library.

> This doesn't mean I'm happy with druntime and phobos, though.

Yep. Additions to std.range like orElse will make idiomatic Phobos code slower then C++ and Scala. It is not clear when you do a benchmark for single implementation, but idiomatic combinations of D Ranges will became slow.

>> This ways are not compatible at least for now.
>
> I must have missed that: Are you saying that someone using druntime in his application will not be able to use "betterC" libraries?

No, betterC libraries can be used by D apps like a common C libs.

>> Mir libraries are going to be betterC, the next great betterC goal is DCV.
>>
>> Ilya
>
> Would it be possible for you to provide a precise specification of what exactly betterC is going to be? Or, if that already exists, and I have missed it, point me to it?

betterC is wide concept. Examples:

A generic betterC library can be used to write precompiled betterC libraries. Example:
https://github.com/libmir/mir-algorithm

A precompiled betterC library in binary form is a library with extern(C) API that can be used without DRuntime by other libraries, apps, and languages (!!!). Examples:

https://github.com/tamediadigital/hll-d
https://github.com/libmir/mir-cpuid
https://github.com/libmir/mir-glas

Why without DRuntime? I had explained this multiple times.
1. DRuntime has not stable ABI between versions
2. DRuntime has not stable ABI between compilers
3. DRuntime depends on GC, D GC is slow, and because D design GC will always will be slow.

1,2,3 are important for real world business. Most of existing D users do not need 1-3 (otherwise they would switch to C). So, I do not expect any understanding from the community about my opinion :P

On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
> Why without DRuntime? I had explained this multiple times.

Could this be captured in a wiki or somewhere in a more positive tone so that new comers are not scared by the first look of it?

> because D design GC will always will be slow.

Can you please elaborate on this? Which design choice and why?

> 1,2,3 are important for real world business.

+1

On Sunday, 5 March 2017 at 08:49:33 UTC, Arun Chandrasekaran wrote:
> On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
>> Why without DRuntime? I had explained this multiple times.
>
> Could this be captured in a wiki or somewhere in a more positive tone so that new comers are not scared by the first look of it?

They are
https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a
https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b

>> because D design GC will always will be slow.
>
> Can you please elaborate on this? Which design choice and why?

Please read this:
http://forum.dlang.org/post/oetnnywqhcedrnvxukcy@forum.dlang.org
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.6zz5an77a

>> 1,2,3 are important for real world business.
>
> +1

On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
> On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner wrote:
>>
>> Please don't throw all "old D users" in the same category, generalizations like that only alienate. On a related note: What I believe in is that D's community can't take another rift like Phobos/Tango, D1/D2, so I've been very skeptical regarding the value of betterC.
>
> I don't care about existing D users. Sorry about that. In the same time I do not see any problem with betterC for existing D users. Any betterC library can be used with Druntime like either a common C library or generic D library.

I'm not asking you to, but imho it would benefit you to care about pushing people away from your betterC idea by misrepresenting them like that (as it steers from a technical discussion to an emotional debate). And since AFAICT you still use a D compiler adhering to a D spec, which likely contains bugs, I do think it would benefit you to care about the D ecosystem as a whole, since the smaller the ecosystem the unlikelier it becomes that bugs in the compiler get detected, reported, and fixed. In any case, as long as you don't intend to create some incompatible rift (which I wasn't clear on up till now) I'm happy.

>
>[...]
>
> No, betterC libraries can be used by D apps like a common C libs.

Ok, thank you for the clear confirmation.

>[...]
>
> betterC is wide concept. Examples:
>
> A generic betterC library can be used to write precompiled betterC libraries. Example:
> https://github.com/libmir/mir-algorithm
>
> A precompiled betterC library in binary form is a library with extern(C) API that can be used without DRuntime by other libraries, apps, and languages (!!!). Examples:
>
> https://github.com/tamediadigital/hll-d
> https://github.com/libmir/mir-cpuid
> https://github.com/libmir/mir-glas

Thanks for the examples, I'll have a look at how they work.

>
> Why without DRuntime? I had explained this multiple times.
> 1. DRuntime has not stable ABI between versions
> 2. DRuntime has not stable ABI between compilers
> 3. DRuntime depends on GC, D GC is slow,

Yeah, I got why you don't want to use druntime (and 1+2 are one one the things I'm not happy about), I just wasn't clear on whether you planned to replace it with something else (or just don't use any runtime, like you are).
This is quite interesting, since the primary reason for druntime's existence IIRC was the Phobos/Tango split where people didn't like Phobos, hence for consolidation, it was split into only the minimal parts to support the language features (druntime) and the new Phobos, so people using different standard libraries for D wouldn't be incompatible (since they share a common druntime).

> and because D design GC will always will be slow.

I was not aware of that: Am I right in understanding here that there is something about the language itself that inherently makes any attempt at using any GC slow? There is no possible way to implement a fast GC for D?

>
> 1,2,3 are important for real world business.

Correct me if I'm wrong, but I was under the impression that Sociomantic Labs was using D1 (which contains the GC that's now in druntime AFAIK) extensively for extremely time-sensitive tasks (web advertisement auctions in the microsecond range IIRC).
Druntime implements the GC and several features in it depend on the GC, yes, but linking against druntime doesn't - AFAIK - necessitate actually using any of those features, i.e. linking against druntime should not inherently result in any slow down. Regardless, I can see why one wouldn't want to link against a library one doesn't actually use.

> Most of existing D  users do not need 1-3 (otherwise they would switch to C).

I agree that most don't seem to need them from my POV, but I don't agree with the assumption that people switching to C is a necessary conclusion from people needing them.

> So, I do not expect any understanding from the community about my opinion :P

This is bordering on being derogative, though, since AFAIK we are supposed to be in a forum for (technical) discussions, not (political) debates, i.e. facts and reasoning are important as opposed to anyone's opinion.
These are the facts as I now see them (after your explanation):
1. You need to expose a stable ABI between compilations/releases of a library
2. You need to be as fast as possible.
3. 1. and 2. are hard requirements, i.e. you cannot change them.
Analysis: Does linking with druntime and/or phobos get in the way of 1. or 2.?
1. If you depend on any symbols from them, yes. Otherwise, no.
2. No
Conclusion: You cannot depend on any symbols from druntime or phobos.
Corollary: You don't need to link against druntime or phobos.

You don't need to worry (or care at all) about anyone's understanding of any of your opinions, you just need to lay out the facts and reason about them.

On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
> On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner [...]
>
>> This doesn't mean I'm happy with druntime and phobos, though.
>
> Yep. Additions to std.range like orElse will make idiomatic Phobos code slower then C++ and Scala. It is not clear when you do a benchmark for single implementation, but idiomatic combinations of D Ranges will became slow.
>

Sorry for the double post, I missed this section in my earlier reply.
Could you elaborate on why that is (probable another link to a discussion I missed xD )?

On Sunday, 5 March 2017 at 09:27:25 UTC, Ilya Yaroshenko wrote:
> [...]
>>
>> Can you please elaborate on this? Which design choice and why?
>
> Please read this:
> http://forum.dlang.org/post/oetnnywqhcedrnvxukcy@forum.dlang.org
> http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
> https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.6zz5an77a
>

Thank you for this, please disregard my request for clarification on this point in my other post.

On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
> 1. DRuntime has not stable ABI between versions
> 2. DRuntime has not stable ABI between compilers

Anyone can shed light on why this is so? Is there just too much evolution at the moment that the ABI needs to be constantly updated? Or was there a failure to include sufficient ABI, name mangling etc. rules into the specificiation? Can this be expected to change in the foreseeable future?

> slow.

This reminds me my last discussion with the C++ guru at work... Every complaint of mine against the language, he argued against in terms of performance. I felt every argument of this could be reused to abandon C++ in favor of C (which would make me happy lol).

On Sunday, 5 March 2017 at 14:27:28 UTC, XavierAP wrote:
> On Sunday, 5 March 2017 at 05:45:19 UTC, Ilya Yaroshenko wrote:
>> 1. DRuntime has not stable ABI between versions
>> 2. DRuntime has not stable ABI between compilers
>
> Anyone can shed light on why this is so? Is there just too much evolution at the moment that the ABI needs to be constantly updated? Or was there a failure to include sufficient ABI, name mangling etc. rules into the specificiation? Can this be expected to change in the foreseeable future?

See [1] and in particular [2] for how horrible this can be if that's something you care about. There's a reason why dub packages are compiled (automatically) locally for your current toolchain.

>
>> slow.
>
> This reminds me my last discussion with the C++ guru at work... Every complaint of mine against the language, he argued against in terms of performance. I felt every argument of this could be reused to abandon C++ in favor of C (which would make me happy lol).

<sarcasm>
Assembler code is best code!
</sarcasm>

[1] https://forum.dlang.org/thread/ivbnsgqoyjrxkkhvzhcg@forum.dlang.org?page=1
[2] https://forum.dlang.org/post/20160421194152.51652783@gmx.de

On 5 March 2017 at 06:45, Ilya Yaroshenko via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 4 March 2017 at 16:43:21 UTC, Moritz Maxeiner wrote:
>>
>> On Saturday, 4 March 2017 at 15:35:13 UTC, Ilya Yaroshenko wrote:
>>>
>>> [...]
>>>>
>>>>
>>>> my 1 cent: we should stop trying to convert C++ users.
>>>
>>>
>>> Please, do no push devs to do not do something. There are two directions: betterC and DRuntime.
>>
>>
>> I've tried to follow the "betterC" discussion, but so far a precise specification of what betterC is supposed to be eluded me. What I got was that you seem to be judging druntime to be too heavyweight and want something more lightweight, but I was never clear on what exactly.
>>
>>> I believe in betterC and  betterC target is C/C++ industry. Old D users are happy with DRuntime and growing Phobos.
>>
>>
>> Please don't throw all "old D users" in the same category, generalizations like that only alienate. On a related note: What I believe in is that D's community can't take another rift like Phobos/Tango, D1/D2, so I've been very skeptical regarding the value of betterC.
>
>
> I don't care about existing D users. Sorry about that. In the same time I do not see any problem with betterC for existing D users. Any betterC library can be used with Druntime like either a common C library or generic D library.
>
>> This doesn't mean I'm happy with druntime and phobos, though.
>
>
> Yep. Additions to std.range like orElse will make idiomatic Phobos code slower then C++ and Scala. It is not clear when you do a benchmark for single implementation, but idiomatic combinations of D Ranges will became slow.
>
>>> This ways are not compatible at least for now.
>>
>>
>> I must have missed that: Are you saying that someone using druntime in his application will not be able to use "betterC" libraries?
>
>
> No, betterC libraries can be used by D apps like a common C libs.
>

Ha!  Did no one tell you any horror stories about people dealing with C++ ABIs?  If this is the essentially the crux of your problem, then you are barking up the wrong tree in blaming druntime for the mess we are allegedly in.


>>> Mir libraries are going to be betterC, the next great betterC goal is DCV.
>>>
>>> Ilya
>>
>>
>> Would it be possible for you to provide a precise specification of what exactly betterC is going to be? Or, if that already exists, and I have missed it, point me to it?
>
>
> betterC is wide concept. Examples:
>
> A generic betterC library can be used to write precompiled betterC
> libraries. Example:
> https://github.com/libmir/mir-algorithm
>
> A precompiled betterC library in binary form is a library with extern(C) API
> that can be used without DRuntime by other libraries, apps, and languages
> (!!!). Examples:
>
> https://github.com/tamediadigital/hll-d https://github.com/libmir/mir-cpuid https://github.com/libmir/mir-glas
>
> Why without DRuntime? I had explained this multiple times. 1. DRuntime has not stable ABI between versions

I was curious to see if there were any ABI changes in GDC with functions that it generates code for, and the first I found was 5 years ago, where _aaDelp (DMD didn't support a non-variadic 'delete aa' at the time) had it's return type changed from void to bool. Changes since then have either been functions added or functions removed - but only *after* the compiler stopped generating calls to it some 2 years down the line.

So I am a bit amused when you say that ABI is not stable.


> 2. DRuntime has not stable ABI between compilers

I think you mean common ABI.  GDC and LDC should be compatible on anything that is extern(C).   Feel free to request an apology from DMD however for using a made up calling convention, which has single-handedly caused the biggest rift between us and them.


> 3. DRuntime depends on GC, D GC is slow, and because D design GC will always will be slow.
>
> 1,2,3 are important for real world business. Most of existing D users do not need 1-3 (otherwise they would switch to C). So, I do not expect any understanding from the community about my opinion :P

I think this deserves only a blink.  Considering that there are some companies out there, using real-time applications that make use of D's GC also (of course, within reason).  The only feedback I can offer you here is that not only should you expect community to not understand you, real world business won't understand you either.

On 03/05/2017 09:27 AM, XavierAP wrote:
>
> This reminds me my last discussion with the C++ guru at work... Every
> complaint of mine against the language, he argued against in terms of
> performance. I felt every argument of this could be reused to abandon
> C++ in favor of C (which would make me happy lol).

What OOP is to Java, and functional is to Haskell, that's what premature optimization is to C/C++.