December 14, 2020
On Sunday, 13 December 2020 at 23:13:24 UTC, Max Haughton wrote:
>
> FWIW, we might benefit from having working groups a la the C++ committee. I'd happily contribute to one on memory safety (I would say I'd start one but I dont trust my knowledge of either DMD internals or formal proofs of this kind of theory).

There are a lot of people in the D community with deep technical knowledge, but weak organizational and interpersonal skills. If you (or someone like you) were willing to reach out to these people and do the administrative work to organize a working group on memory safety, that would be a very valuable contribution.
December 14, 2020
On Sunday, 13 December 2020 at 22:18:26 UTC, IGotD- wrote:
>
> D needs to differentiate managed and raw pointers, this has to be done in order to get out of the tracing GC swamp.

I think `@live` without that differentation does the job better. It is a relatively cheap solution that does not even try to be perfect. The managed-unmanaged pointers are better in theory, as they can be more foolproof, but they have many times as much complexity. Since most of the code can avoid memory corruption simply by using the GC, I doubt whether closing that gap in `@live` is worth that much.
December 14, 2020
On Monday, 14 December 2020 at 13:12:55 UTC, Dukc wrote:
>
> I think `@live` without that differentation does the job better. It is a relatively cheap solution that does not even try to be perfect. The managed-unmanaged pointers are better in theory, as they can be more foolproof, but they have many times as much complexity. Since most of the code can avoid memory corruption simply by using the GC, I doubt whether closing that gap in `@live` is worth that much.

I would really like to know more about how @live together with the supposedly reference counting without fat pointers is supposed to work. I haven't seen any comprehensive document that explains it. Reference counting without fat pointers is an oxymoron as far as I understand. Maybe someone can explain.

I think that is what's missing, what the plan is for this.
December 14, 2020
On Sunday, 13 December 2020 at 23:08:05 UTC, IGotD- wrote:
> On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:
>>
>> It's easy to sit around in our armchairs pontificating about how, if only "the D community" (read: someone else) would do X, Y, or Z, all of our problems would be solved.
>>
>> It's harder, but ultimately much more rewarding, to roll up one's sleeves and actually make a positive contribution.
>
> This is not a one man job which someone can make a neat preview of. It's a decision that has to be made from the maintainers so that several people can start working with such a big task. Also documenting what needs to be done. This ties into the original post with the blog post, that the D project has problems with rallying people towards a common goal (which today is very vague).
>
> People starting to add and change things randomly and then hoping that it will be accepted and be merged isn't really a good way to run a project.

Very well put.

The main point of my post is that "What needs to be done" isn't documented so unless you've spent some time in the community to identify the issues out of experience or see them as they pop up here in the forum.

Hence D needs a Project Manager in addition to the PR Manager (wait what happened to the PR manager?). I know devs don't like project managers but the absence of such a person might not speak well to certain companies/individuals looking to invest in D (even if they like it). Isn't that one of the reasons why we have a foundation in the first place? Without knowing the high-level roadmap or core language priorities, what's there to invest in? What about those looking for interesting problems for their thesis? New volunteers?

BeerConf has created room for community members to chat and discuss D issues, and some ideas/mobilization has come from that. It's a similar thing for why there needs to be a roadmap or (at least) a priority list of some kind.

Individualism simply isn't going to cut it.
December 14, 2020
On Mon, Dec 14, 2020 at 07:42:41PM +0000, aberba via Digitalmars-d wrote: [...]
> Hence D needs a Project Manager in addition to the PR Manager (wait what happened to the PR manager?). I know devs don't like project managers but the absence of such a person might not speak well to certain companies/individuals looking to invest in D (even if they like it).
[...]

I've said this before, we coders just aren't good at project management. We need someone with the right set of skills to give direction to us coders.  Preferably someone with some dev background who can sympathize with the dev side of things.  But people don't seem receptive to this idea.  Oh well.


T

-- 
My program has no bugs! Only unintentional features...
December 15, 2020
On Monday, 14 December 2020 at 19:42:41 UTC, aberba wrote:
> On Sunday, 13 December 2020 at 23:08:05 UTC, IGotD- wrote:
>> [...]
>
> Very well put.
>
> The main point of my post is that "What needs to be done" isn't documented so unless you've spent some time in the community to identify the issues out of experience or see them as they pop up here in the forum.
>
> [...]

The PR manager position is in the process of being filled. It's not our money being spent so these things take time.
December 15, 2020
On Sunday, 13 December 2020 at 20:35:15 UTC, H. S. Teoh wrote:
> On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via Digitalmars-d wrote: [...]
>> I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users.
>
> Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  For most normal applications the GC is actually a big plus.


D's biggest problem are those trying to turn it into C++.
December 15, 2020
On Tuesday, 15 December 2020 at 08:13:31 UTC, Dylan Graham wrote:
> On Sunday, 13 December 2020 at 20:35:15 UTC, H. S. Teoh wrote:
>> On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via Digitalmars-d wrote: [...]
>>> I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users.
>>
>> Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  For most normal applications the GC is actually a big plus.
>
>
> D's biggest problem are those trying to turn it into C++.

With the irony that most prominent C++ game engines, and OS component frameworks, do use some form of automatic memory management.
December 15, 2020
On Tuesday, 15 December 2020 at 09:11:26 UTC, Paulo Pinto wrote:
> With the irony that most prominent C++ game engines, and OS component frameworks, do use some form of automatic memory management.

None of these systems confuses GC'ed with non GC'ed pointers. C++ for all its warts doesn't have this flaw.
December 15, 2020
On Tuesday, 15 December 2020 at 09:31:40 UTC, Araq wrote:
> On Tuesday, 15 December 2020 at 09:11:26 UTC, Paulo Pinto wrote:
>> With the irony that most prominent C++ game engines, and OS component frameworks, do use some form of automatic memory management.
>
> None of these systems confuses GC'ed with non GC'ed pointers. C++ for all its warts doesn't have this flaw.

That I agree, but the problem isn't with the GC, rather the implementation thereof.

Probably the easiest way for D not to break (much) code would be to keep all pointers as GC pointers by default, and non-GC pointers would be the ones marked with @system.

This isn't a novelty, and follows a design similar to other system languages with GC support.