Thoughts about D

[Iain Buclaw]

On 3 December 2017 at 00:56, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 12/2/2017 4:13 AM, Iain Buclaw wrote:
>>
>> On 29 November 2017 at 03:18, Walter Bright via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> On 11/28/2017 9:27 AM, Jacob Carlborg wrote:
>>>>
>>>>
>>>> Why would druntime be a barrier for you for those projects?
>>>
>>>
>>>
>>> When the C version is 90K and the translated D version is 1200K, it is a
>>> barrier. It's a barrier for others, as well.
>>>
>>
>> Did you add an extra 0 here for the D version?
>
>
> No. I used the sizes for MicroEmacs in C vs MicroEmacs in D. (I translated
> the former into the latter.)
>
> With BetterC, I've been able to create virtually identical binaries for C
> and D.
>
>

Ah, you're referring to binary sizes.  Well you have two central
components which do well to bolster that, core.thread and the GC.

I guess if your project is to port something from C to D.  You'd start
out with `extern(C) int main() @nogc` and go from there.  That then
leaves moduleinfo, to which there already exists the machinery in the
compiler for determining whether it needs to be generated, dmd could
start using it again instead of defaulting to always generating
moduleinfo symbols that pull in druntime.  That would mean a switch
that gives fine control over generation
(-moduleinfo=[on|asneeded|off]), still better than a betterC feature
gate.


>>> Another barrier for me has turned out to be the way assert() works in D.
>>> It
>>> just is not lightweight, and it visibly slows down dmd to have assert's
>>> turned on internally. The amount of machinery involved with it in
>>> druntime
>>> is way overblown. Hence, asserts in dmd are turned off, and that wound up
>>> causing me a lot of problems recently. There are even initiatives to add
>>> writefln like formatting to asserts. With betterC, asserts became
>>> lightweight and simple again.
>>
>> I find this assertion hard to believe (pun not intended).  Unless you
>> are omitting some extra check (invariant calls?), whether you are
>> using D's assert or C's assert, both have the same runtime cost.
>
>
> asserts are significantly larger in D. One reason is the filename string is
> passed as a D string, which is 2 pushes. A C string is one push.
>

D strings require one extra push, true.  But what's that, one extra
clock cycle?  Not even the cost of half a crown.


> Consider that D asserts throw an exception. Where's the catch going to be,
> if you're linking the D code into a C program? And the D personality
> function, needed for D exception unwinding, is in druntime.
>

If there is no catch, what happens is that unwind raise exception
returns end of stack, and you abort in the throw() function.


>
>>> BetterC is a door-opener for an awful lot of areas D has been excluded
>>> from,
>>> and requiring druntime is a barrier for that.
>>
>> It's not a door opener, and druntime is not a barrier.
>
>
> If you have a C program, and want to add a D function to it, you really
> don't want to add druntime as well. BetterC enables people to provide D
> addon libraries for people who have C main programs.
>
> There's a point to making incremental use of D as low cost as possible.
>

People have been making alternative druntime libraries for a while
now, either as stubs inside their own project, or by using minilibd.
There's nothing stopping you from simply swapping out druntime for
another implementation.