June 24, 2022
On 6/23/2022 10:26 PM, forkit wrote:
> But I think is was motivated by someone actually wanting to make it more popular, not less popular.

Unhelpful Hairshirt: Why is D unpopular?

Helpful: How can we expand D into new areas?
June 24, 2022

On Friday, 24 June 2022 at 19:51:29 UTC, Walter Bright wrote:

>

Hence, in the interest of maximum performance for most code, D does not insert write gates in the generated code.

Waiting for "all" threads to hit a checkpoint is not maximum performance…

June 24, 2022
On 6/24/22 23:01, Walter Bright wrote:
> On 6/23/2022 10:26 PM, forkit wrote:
>> But I think is was motivated by someone actually wanting to make it more popular, not less popular.
> 
> Unhelpful Hairshirt: Why is D unpopular?
> 
> Helpful: How can we expand D into new areas?

Allow me to disagree. Trying to expand D in its current state is not helpful. Example of helpful could be: let's polish features we have and fix at least majority of reported bugs.
June 24, 2022
On 6/24/2022 12:57 PM, rikki cattermole wrote:
> At some point its going to have to be implemented as opt-in if we want to allow people to experiment with them.

Since D does not distinguish between gc and non-gc pointers, it would be a heavy penalty.

Consider the following:

    struct S { ... }

    class C { int a; S s; }

In Java, an instance of C would require two different allocated objects. This is a heavy burden on the GC, and justifies the write gates. Even if D allocations were all on the GC, D just does not have such a heavy reliance on the GC, and so write gates are much less justifiable.

It's also kinda off-topic for this thread. I don't really want to debate gc or non-gc here, just pointing out how positive framing can be while still being totally honest.
June 24, 2022
On 6/24/2022 1:18 PM, drug007 wrote:
> Example of helpful could be: let's polish features we have and fix at least majority of reported bugs.

That's more hairshirt wearing.

Better: continuously improve features based on experience and stay in the vanguard of modern language technology
June 24, 2022
On Friday, 24 June 2022 at 19:58:32 UTC, Walter Bright wrote:
> On 6/24/2022 4:59 AM, Dukc wrote:
>> Did he just help you market existing features in your C compiler, or did he point out what features you should add to win sales?
>
> He knew how to work with magazines and journalists. He knew how to design advertisements. He knew how to bundle it with other desirable products. He'd organize press events. He knew how to frame the compiler's capabilities in a very positive (but still accurate) light. He knew how to put the product in an attractive box that was a pleasure to have on one's shelf.

Yes, I tend to believe that this kind of stuff is as important to become popular as getting the engineering right. It's also something that I'm definitely not known at being good at. That's why it's good that you reviewed my D blog post before it went public.

Anyone who wants D to become popular should think about this when posting at these forums, or HN, or Reddit, etc. Not at the expense of being clear about issues. But it's just stupid to spend evenings contributing issue reports and code, and then miss easy opportunities to attract more users when talking about the language.


June 24, 2022
On Sat, Jun 25, 2022 at 07:57:03AM +1200, rikki cattermole via Digitalmars-d wrote:
> 
> On 25/06/2022 7:51 AM, Walter Bright wrote:
> > Honesty - Since Java is heavily dependent on the gc, it is worth it to insert write gates into the generated code to accurately track usage of gc allocated memory. Usage of D's gc is optional, and D's semantics are much less reliant on the gc. Hence, in the interest of maximum performance for most code, D does not insert write gates in the generated code.
> 
> Unfortunately pretty much all the advanced GC's require write barriers.
> 
> We are almost maxed out on what we can do.
> 
> At some point its going to have to be implemented as opt-in if we want to allow people to experiment with them.

Experimenting with advanced GCs is definitely something worth exploring IMO.

Memory-related bugs are a constant scourge in code with manual memory management.  Random example: this week I just got another chromium update from my distro, fixing a bunch of issues. 4/9 issues were use-after-free bugs. Out of curiosity, I did a little investigation to get an idea of just how prevalent use-after-free bugs are. Here's a brief run-down:

- 21 Jun 2022: 4 use-after-free bugs.
- 10 Jun 2022: 2 use-after-free bugs.
- 25 May 2022: 12 use-after-free bugs.
- 10 May 2022: 7 use-after-free bugs.
- 26 Apr 2022: 11 use-after-free bugs.
- 11 Apr 2022: 6 use-after-free bugs.
- 1 Apr 2022: 9 use-after-free bugs.
- 16 Mar 2022: 9 use-after-free bugs.
- 2 Mar 2022: 8 use-after-free bugs.
- 15 Feb 2022: 6 use-after-free bugs.
- 5 Feb 2022: 11 use-after-free bugs.
- 19 Jan 2022: 12 use-after-free bugs.

In total, there were a whopping 97 use-after-free bugs from the beginning of the year until now.  And this is just *one* of numerous memory-related bugs, in *one* piece of software. A disproportionately large number of bugs per update are memory-related problems, such as use-after-free, out-of-bounds memory access, heap buffer overflow, etc.. And mind you, these are only the bugs that were *discovered* and reported. I suspect a fair number of them lie latent, either undiscovered or discovered but unreported by unscrupulous parties.

Manual memory management may have its place, perhaps in low-level code in the kernel or something, but in application code it's just a constant source of bugs and a non-stop drain on resources to find and fix said bugs.  It's time the world moved on to GC'd languages. And for that, D needs a competitive GC.  If write barriers are what it takes to get one, then it's well worth the effort IMO.


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton
June 24, 2022
On Friday, 24 June 2022 at 19:51:29 UTC, Walter Bright wrote:
> On 6/23/2022 10:30 PM, forkit wrote:
>> Just wear something under it. It'll make it a little less uncomfortable.
>
> What I mean by wearing a hairshirt is insistence on negging D. There are many ways to be honest about D's capabilities without describing them in negative terms.
>
> ...

Saying something in a postive way, is not necessarily good.

Saying something in a negative way, is not necessarily bad.

What is important, is the motivation - which is not always clear, whether the message was delivered in a positive way, or a negative way.

In any case. I better understand your point, and for the most part, accept it.

Certainly too much negativity, or negativity motivated by an excessive pursuit of ones own goals - ;-)  .. can, and almost certainly will, have an aversive effect.

But I'm struggling to see a day, where people in the D forums, sit around a fire together, and start singing kumbaya, in harmony with each other.

The struggle to balance self-oriented goals against group-oriented goals, has always existed, and will continue to exist for some time yet... even in the D community.


June 25, 2022
On Friday, 24 June 2022 at 23:12:02 UTC, forkit wrote:

>
> But I'm struggling to see a day, where people in the D forums, sit around a fire together, and start singing kumbaya, in harmony with each other.
>

Then you've never been to DConf. That's metaphorically what we do, especially in the evenings when we gather for BeerConf, but also between the talks and during the Hackathon. I'm not saying everyone agrees all the time, but any debates that are had have a much, much different tone when they're face-to-face than they do in the forums.
June 25, 2022
On 25.06.22 00:02, Dukc wrote:
>>
>> He knew how to work with magazines and journalists. He knew how to design advertisements. He knew how to bundle it with other desirable products. He'd organize press events. He knew how to frame the compiler's capabilities in a very positive (but still accurate) light. He knew how to put the product in an attractive box that was a pleasure to have on one's shelf.
> 
> Yes, I tend to believe that this kind of stuff is as important to become popular as getting the engineering right. It's also something that I'm definitely not known at being good at. That's why it's good that you reviewed my D blog post before it went public.
> 
> Anyone who wants D to become popular

D is already popular.