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.

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.

Andrei's been directing some work on using templates more in druntime to reduce this, such as Lucia's work. Martin has done some work with array ops, too.

Exception handling support has been a bloat problem, too. DMC++ is built with all exceptions turned off. I've been writing PRs for dmd to greatly improve things so that it can generate similar code for RAII. (Exceptions require druntime.)

BetterC is a door-opener for an awful lot of areas D has been excluded from, and requiring druntime is a barrier for that.

On Tue, Nov 28, 2017 at 06:18:20PM -0800, Walter Bright via Digitalmars-d wrote: [...]
> 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.
> 
> 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.
> 
> Andrei's been directing some work on using templates more in druntime to reduce this, such as Lucia's work. Martin has done some work with array ops, too.
> 
> Exception handling support has been a bloat problem, too. DMC++ is built with all exceptions turned off. I've been writing PRs for dmd to greatly improve things so that it can generate similar code for RAII. (Exceptions require druntime.)
> 
> BetterC is a door-opener for an awful lot of areas D has been excluded from, and requiring druntime is a barrier for that.

Doesn't this mean that we should rather focus our efforts on improving druntime instead of throwing out the baby with the bathwater with BetterC?

For example, the way assert() works, if indeed it's overblown, then shouldn't we rather fix/improve it?

While generally I would still use fullblown D rather than BetterC for my projects, the bloat from druntime/phobos does still bother me at the back of my mind.  IIRC, the Phobos docs used to state that the philosophy for Phobos is pay-as-you-go. As in, if you don't use feature X, the code and associated data that implements feature X shouldn't even appear in the executable. It seems that we have fallen away from that for a while now.  Perhaps it's time to move D back in that direction.


T

-- 
I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem.  In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright

On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
> On Tue, Nov 28, 2017 at 06:18:20PM -0800, Walter Bright via Digitalmars-d wrote: [...]
>> BetterC is a door-opener for an awful lot of areas D has been excluded from, and requiring druntime is a barrier for that.
>
> Doesn't this mean that we should rather focus our efforts on improving druntime instead of throwing out the baby with the bathwater with BetterC?

Isn't it possible to do both? For example, make D's GC a precise one (thus improving the runtime) and making the experience of using D sans GC and runtime a simple one?

In answer to your question, if D is excluded from a lot of areas on account of requiring druntime, then it may be that no version of what you expect from druntime (I'll use GC as an obvious example) will remove that barrier.

On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
> While generally I would still use fullblown D rather than BetterC for my projects, the bloat from druntime/phobos does still bother me at the back of my mind.  IIRC, the Phobos docs used to state that the philosophy for Phobos is pay-as-you-go. As in, if you don't use feature X, the code and associated data that implements feature X shouldn't even appear in the executable. It seems that we have fallen away from that for a while now.  Perhaps it's time to move D back in that direction.

If there specific apps where druntime and/or phobos bloat is thought to be too high, it might be worth trying the new LDC support for building a binary with druntime and phobos compiled with LTO (Link Time Optimization). I saw reduced binary sizes on my apps, it'd be interesting to hear other experiences.

On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:

> Doesn't this mean that we should rather focus our efforts on improving druntime instead of throwing out the baby with the bathwater with BetterC?

Exactly!  We should be making a better D, not a better C.

Mike

On Thursday, 30 November 2017 at 00:05:10 UTC, Michael V. Franklin wrote:
> On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
>
>> Doesn't this mean that we should rather focus our efforts on improving druntime instead of throwing out the baby with the bathwater with BetterC?
>
> Exactly!  We should be making a better D, not a better C.
>
> Mike

There is no better C, than C, full stop.

-betterC  should become ..   -slimD

But we really do need a focus on both -slimD and -bloatyD

For D to be successful, it needs to be a flexible language that enables programmer choice. We don't all have the same problems to solve.

C is not successful because of how much it constrains you.

On Thursday, 30 November 2017 at 00:23:10 UTC, codephantom wrote:
> On Thursday, 30 November 2017 at 00:05:10 UTC, Michael V. Franklin wrote:
>> On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
>>
>>> Doesn't this mean that we should rather focus our efforts on improving druntime instead of throwing out the baby with the bathwater with BetterC?
>>
>> Exactly!  We should be making a better D, not a better C.
>>
>> Mike
>
> There is no better C, than C, full stop.
>
> -betterC  should become ..   -slimD
>
> But we really do need a focus on both -slimD and -bloatyD
>
> For D to be successful, it needs to be a flexible language that enables programmer choice. We don't all have the same problems to solve.
>
> C is not successful because of how much it constrains you.

I'm personally a big believer that the thing that will replace C is going to be something that is flexible, but more than anything prevents the security bugs that plague the web right now. Things like heartbleed are preventable with safety guarantees that don't prevent fast code. Rust has some good ideas, but so does D.

On 11/29/2017 8:57 AM, H. S. Teoh wrote:
>> BetterC is a door-opener for an awful lot of areas D has been excluded
>> from, and requiring druntime is a barrier for that.
> Doesn't this mean that we should rather focus our efforts on improving
> druntime instead of throwing out the baby with the bathwater with
> BetterC?

What BetterC does is shine a spotlight on these issues. They've also come up with Ilya Yaroshenko's work.


> For example, the way assert() works, if indeed it's overblown, then
> shouldn't we rather fix/improve it?

I've tried, and met a lot of resistance.

On 11/29/2017 3:36 PM, Jon Degenhardt wrote:
> On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
>> While generally I would still use fullblown D rather than BetterC for my projects, the bloat from druntime/phobos does still bother me at the back of my mind.  IIRC, the Phobos docs used to state that the philosophy for Phobos is pay-as-you-go. As in, if you don't use feature X, the code and associated data that implements feature X shouldn't even appear in the executable. It seems that we have fallen away from that for a while now.  Perhaps it's time to move D back in that direction.
> 
> If there specific apps where druntime and/or phobos bloat is thought to be too high, it might be worth trying the new LDC support for building a binary with druntime and phobos compiled with LTO (Link Time Optimization). I saw reduced binary sizes on my apps, it'd be interesting to hear other experiences.

Ideally, the druntime library should be come with the operating system so every user has a copy of it. Practically, I can't see that happening for the foreseeable future. It doesn't even happen for Windows with Microsoft's own compiler.

On 11/29/17 9:16 PM, Walter Bright wrote:
> On 11/29/2017 3:36 PM, Jon Degenhardt wrote:
>> On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
>>> While generally I would still use fullblown D rather than BetterC for my projects, the bloat from druntime/phobos does still bother me at the back of my mind.  IIRC, the Phobos docs used to state that the philosophy for Phobos is pay-as-you-go. As in, if you don't use feature X, the code and associated data that implements feature X shouldn't even appear in the executable. It seems that we have fallen away from that for a while now.  Perhaps it's time to move D back in that direction.
>>
>> If there specific apps where druntime and/or phobos bloat is thought to be too high, it might be worth trying the new LDC support for building a binary with druntime and phobos compiled with LTO (Link Time Optimization). I saw reduced binary sizes on my apps, it'd be interesting to hear other experiences.
> 
> Ideally, the druntime library should be come with the operating system so every user has a copy of it. Practically, I can't see that happening for the foreseeable future. It doesn't even happen for Windows with Microsoft's own compiler.

But even though it doesn't come with Windows, it can be installed once, and shared between all applications that use it.

The issue with druntime isn't that it's not installed, it's the static linking.

A second problem is that due to the way D works most of the time (with templates just about everywhere), each new release is likely to be binary-incompatible. So you will essentially need many copies of druntime, probably one per release that was used to compile any D programs on your system. But this is much less of an issue, especially if there are many programs that build using the same release.

-Steve