D street cred: Just a thought

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Sun Mar 5 08:46:13 PST 2017


On 5 March 2017 at 06:45, Ilya Yaroshenko via Digitalmars-d
<digitalmars-d at 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.


More information about the Digitalmars-d mailing list