On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
> What I really want is what C++ wanted to deliver but it doesn't. I want something better than writing C but with the same performance as C and the ability to interface with C without the performance loss and with easily composable libraries.
>
> D in my opinion in some ways is close to these goals. It's simpler to understand and write than C++. It has the problem of being a GC'd language however and it's unclear to me if the GC in D is evolving like the Go GC is. ...
>
> The things I really want from D to really sway me would be the following (some already exist):
> 1. Evolve the GC like Go has.
> 2. No overhead calling C libraries.
> ...

Bad news: without complete redesign of the language and turning into one more C++/CLI (where you have different kinds of pointers in the language for GC and non-GC), having C performance and Go-style low-pause GC is not really possible. You have to choose one. Go chose GC with short pauses but paid with slow speed overall and slow C interop. D chose C-level performance but paid for it with a slow GC.

On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
> On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
>> [...]
>
> Bad news: without complete redesign of the language and turning into one more C++/CLI (where you have different kinds of pointers in the language for GC and non-GC), having C performance and Go-style low-pause GC is not really possible. You have to choose one. Go chose GC with short pauses but paid with slow speed overall and slow C interop. D chose C-level performance but paid for it with a slow GC.

If this is true, a blog post about it with more details is very welcome --Ilya

On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko wrote:
> On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
>> On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
>>> [...]
>>
>> Bad news: without complete redesign of the language and turning into one more C++/CLI (where you have different kinds of pointers in the language for GC and non-GC), having C performance and Go-style low-pause GC is not really possible. You have to choose one. Go chose GC with short pauses but paid with slow speed overall and slow C interop. D chose C-level performance but paid for it with a slow GC.
>
> If this is true, a blog post about it with more details is very welcome --Ilya

You may want to open PR for Mir Blog: https://github.com/libmir/blog

On Tuesday, 20 December 2016 at 16:22:43 UTC, Walter Bright wrote:
> D is quite a bit less formal, but still, if you want action consider that you aren't going to get it with any organization unless you're willing to:
>
> 1. pay others to do it
>
> 2. convince others that your important issues are more important than everyone else's important issues that they are already working on
>
> 3. put some effort into it yourself
>
> This includes C, C++, Java, Go, Rust, basically every language in existence.
>
> ---
>
> Note that pretty much every day in the D forums, people post lists of their most important issues they want other people to work on. And the lists are always different.
>
> When people invest time into solving the problems they complain about, that's evidence that those issues are more important. It's the same in C++ land - a common sentiment among the C++ stars is that if someone isn't willing to make an effort to write a proposal to the C++ Committee, it isn't an issue worth their time, either.
>
> It really can't be any other way.

What about the first way in your list ("pay others to do it")? From what I gather, this was one of the reasons for founding the D Foundation.

There are many "boring" tasks that few people seem interested in doing: improving the documentation, maintaining the website, improving the forum system (it lacks many important features IMHO), improving IDE support for D (I have no idea how one would go about doing this but it's important), etc. (The vision document in the D wiki contains many more such "boring" tasks).

And the few people that do work on the "boring" stuff seem to be the "wrong" people. One does not need to be a compiler expert or a metaprogramming guru to work on the tasks mentioned. That would be a bad use of that person's time - his/her skills lie elsewhere. If no one is interested in doing this stuff then maybe it's a good idea for the D Foundation to hire some people who'll dedicate their time to these issues. I do not think that this would be a bad use of the foundation's funds.

On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko wrote:
> On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
>> On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
>>> [...]
>>
>> Bad news: without complete redesign of the language and turning into one more C++/CLI (where you have different kinds of pointers in the language for GC and non-GC), having C performance and Go-style low-pause GC is not really possible. You have to choose one. Go chose GC with short pauses but paid with slow speed overall and slow C interop. D chose C-level performance but paid for it with a slow GC.
>
> If this is true, a blog post about it with more details is very welcome --Ilya

Have you seen this one?
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

On Wednesday, 21 December 2016 at 14:50:31 UTC, thedeemon wrote:
> On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko wrote:
>> On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
>>> [...]
>>
>> If this is true, a blog post about it with more details is very welcome --Ilya
>
> Have you seen this one?
> http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

Thanks for the link, will read

On Wednesday, 21 December 2016 at 14:50:31 UTC, thedeemon wrote:
> On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko wrote:
>> On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
>>> On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
>>>> [...]
>>>
>>> Bad news: without complete redesign of the language and turning into one more C++/CLI (where you have different kinds of pointers in the language for GC and non-GC), having C performance and Go-style low-pause GC is not really possible. You have to choose one. Go chose GC with short pauses but paid with slow speed overall and slow C interop. D chose C-level performance but paid for it with a slow GC.
>>
>> If this is true, a blog post about it with more details is very welcome --Ilya
>
> Have you seen this one?
> http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

A recent blog post regarding the Go garbage collector with pertinent info: https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e

On 12/21/2016 6:24 AM, Mark wrote:
> I do not think that this would be a bad use of the
> foundation's funds.

That is one of the purposes of the Foundation.

On Tue, 20 Dec 2016 08:20:32 +0000, LiNbO3 wrote:
> And have the patch wait in the PR queue until the end of time, not even acknowledged at all ?

When I've put in PRs for doc improvements, they've been reviewed relatively quickly.

On Wed, 21 Dec 2016 11:36:14 +0000, thedeemon wrote:
> Bad news: without complete redesign of the language and turning into one more C++/CLI (where you have different kinds of pointers in the language for GC and non-GC), having C performance and Go-style low-pause GC is not really possible. You have to choose one. Go chose GC with short pauses but paid with slow speed overall and slow C interop. D chose C-level performance but paid for it with a slow GC.

You can implement write barriers as runtime calls, but omit them in @nogc code. However, this would be costly -- it's an expensive technique in general; the current GC mallocs each object instead of mmaping a range of memory; and in D you can't move heap objects safely, so you can't distinguish generations based on pointers (you'd have to mark GC data structures, and it's O(log n) to find the right one).

You can implement write barriers with mprotect. However, this won't give you good granularity. You just know that someone wrote something to an 8 kilobyte block of memory that has a pointer in it somewhere. This requires the GC to use mmap instead of malloc, and it is strongly encouraged not to put pointer-free objects in the same page as objects with pointers.