On 1/15/21 4:55 PM, Ola Fosheim Grøstad wrote:
> On Friday, 15 January 2021 at 21:18:55 UTC, aberba wrote:
>> TL;DR:
>>
>>> In summation, the garbage collection system is a robust part of Unreal Engine that affords C++ programmers a lot of safety from memory leaks, as well as convenience. With this high-level discussion, I was aiming to introduce the system at a conceptual level, and I hope I have achieved that.
> 
> What is your conceptual level? You haven't described what it does, and does not do. But yes, frameworks need that allow "scripting" in some shape or form (compiled or not) has to hide internal structures and intricacies and provide some convenience.

Those were not aberba's words, but the author of the first link, in which one does find a conceptual, high level description of GC.

On Monday, 18 January 2021 at 01:41:35 UTC, James Blachly wrote:
> Those were not aberba's words, but the author of the first link, in which one does find a conceptual, high level description of GC.

I read it, it said nothing of relevance to the D collector. That is not TLDR informative.

On Monday, 18 January 2021 at 07:11:20 UTC, Ola Fosheim Grostad wrote:
> On Monday, 18 January 2021 at 01:41:35 UTC, James Blachly wrote:
>> Those were not aberba's words, but the author of the first link, in which one does find a conceptual, high level description of GC.
>
> I read it, it said nothing of relevance to the D collector. That is not TLDR informative.

It talks how the use of GC is desired even in a game engine like Unreal. Several AAA title's have been built on Unreal.

Apparently you can't convince people who have made up their mind about GC being a bad thing for D.

Nevertheless, GC in D isn't going anywhere. And if the approach for writing nogc code in D doesn't cut it, then I'm not what else will.

On Monday, 18 January 2021 at 11:43:20 UTC, aberba wrote:
> Nevertheless, GC in D isn't going anywhere. And if the approach for writing nogc code in D doesn't cut it, then I'm not what else will.

As long as that attitude prevails, D will be going nowhere as well.

On Monday, 18 January 2021 at 11:55:46 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 18 January 2021 at 11:43:20 UTC, aberba wrote:
>> Nevertheless, GC in D isn't going anywhere. And if the approach for writing nogc code in D doesn't cut it, then I'm not what else will.
>
> As long as that attitude prevails, D will be going nowhere as well.

I meant it as this. English is not my native language so pardon my phrasing if it doesn't sound right.


I'm not aware of an alternative way of writing D code aside what already comes with it by default.

If you read the Origin of D book, you would see that the GC was a desire thing when D was designed probably due to how useful it is for ... as said, 90% or so of software development. So at this point, fighting the GC isn't (in my opinion) the right strategy.

I should also say that I notice your point about improving GC in D and making it more optional as much as possible for things that still rely on GC...ARC, etc. 👍


The OP was about why programmers don't "like" GC. I've been here long enough to see the GC being one of the most re-occurring issues for discussion (probably due to new users coming in). There's been official posts about how D's style of GC isn't like that of fully managed languages, how to write nogc code in D, how to minimize GC, among others.

Now if none of these work for you (for some special reason), then the long-term strategy might be an alternative runtime and or std. Which isn't a good answer that thought was worth it...so I didn't include that.

If none of these work, then I (as in my personal opinion), don't know what else is available.

On Mon, Jan 18, 2021 at 11:43:20AM +0000, aberba via Digitalmars-d-learn wrote: [...]
> It talks how the use of GC is desired even in a game engine like Unreal.  Several AAA title's have been built on Unreal.
> 
> Apparently you can't convince people who have made up their mind about GC being a bad thing for D.

'Tis what I've been saying.


> Nevertheless, GC in D isn't going anywhere. And if the approach for writing nogc code in D doesn't cut it, then I'm not what else will.

Nothing ever will. It's exactly like Walter has always said: X (substitute any of the usual complaints for X, like the GC) isn't the real problem. X is just the excuse. You can pour blood and sweat into "fixing" X, but that will not convince the naysayers.  They will just move on to Y. You can proceed to fix Y, but they will just move on to Z. It's a waste of time bending over backwards to please non-customers who have already made up their minds and will never be customers.

Instead, we should be improving life for the existing customers. Like improve the docs, improve dub, fix regressions, etc..


T

-- 
It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.

On Friday, 15 January 2021 at 21:49:07 UTC, H. S. Teoh wrote:
> On Fri, Jan 15, 2021 at 09:04:13PM +0000, welkam via Digitalmars-d-learn wrote:
>> [...]
>
> As the joke goes, "you can write assembly code in any language". :-D  If you code in a sloppy way, it doesn't matter what language you write in, your program will still suck.  No amount of compiler magic will be able to help you.  The solution is not to blame this or that, it's to learn how to use what the language offers you effectively.
>
> [...]

+1 for this.

We should/could improve the GC instead of fighting it 🌟

On Monday, 18 January 2021 at 12:17:24 UTC, aberba wrote:
> If you read the Origin of D book, you would see that the GC was a desire thing when D was designed probably due to how useful it is for ... as said, 90% or so of software development. So at this point, fighting the GC isn't (in my opinion) the right strategy.

Not fighting the GC, but the whole argument about improving it, or mix or match, does not work for most developers looking for a new language. So either there has to be something else or the language semantics will have to be adjusted to get a better GC. That is the crux, the GC cannot be significantly improved without some minor adjustment to the language (with some breaking changes).

To get there the majority have to be in favour of it. If 50% of the D community pulls strongly in the opposite direction, then the GC cannot improve in a meaningful way.

Yes, it is natural that the current D population don't mind the current GC. Otherwise they would be gone... but then you have to factor in all the people that go through the revolving door and does not stay. If they stayed the eco system would be better. So the fact that they don't... is effecting everyone in a negative way (also those that har happy with the runtime).


> I should also say that I notice your point about improving GC in D and making it more optional as much as possible for things that still rely on GC...ARC, etc. 👍

ARC is a pretty big change, so it will depend on library authors supporting it. It also requires a new intermediate representation. So I don't think it will happen. Thread local GC seems most reasonable. As CPUs get more and more threads it becomes more and more unacceptable to lock all threads during collection.

> The OP was about why programmers don't "like" GC.

Programmers like GC, just not for system level programming. C++ has had the Boehm GC since the mid 90s. Only a tiny percentage use it. Forget about game engines, many games have game contents written in Lua and other scripting languages and can live with incremental GC with very little impact on interaction (you could use Javascript too). The game engine itself is usually not relying on GC, just the game content part.


> I've been here long enough to see the GC being one of the most re-occurring issues for discussion (probably due to new users coming in).

Yes, they come in, but do they stay? If they don't stay, then our eco system suffers from it.

D would be in a better position by tracking why people leave and then fix those concerns (if they are related to the language/runtime).

> There's been official posts about how D's style of GC isn't like that of fully managed languages, how to write nogc code in D, how to minimize GC, among others.

Yes, but people who are well versed in system level programming know how to to this already, they just want more hassle than they get in other languages. And those are also the same people that would write solid libraries/improve on the compiler. So not being able to retain those developers is a biiiiig loss.


> Now if none of these work for you (for some special reason), then the long-term strategy might be an alternative runtime and or std. Which isn't a good answer that thought was worth it...so I didn't include that.

Actually that is a good answer, if it comes with the appropriate language changes, like tagged unions and banning conflicting pointers in unions.

What works for me, is not the issue, but what IS the direction?? Where are we going? That is the real issue.

I am perfectly ok with C++20 for low level programming. I don't need D for that. It is totally OK if the D community decides to make it more high level and easier to deal with for newbies who come from Python.


> If none of these work, then I (as in my personal opinion), don't know what else is available.

I am ok with any one of these alternatives:

Alternative 1: Adjust the language semantics so that the GC can be improved and accept some breaking changes.

Alternative 2: Switch focus from being a system level language to becoming more of a high level language.

Alternative 3: Implement ARC.

The other alternatives don't really work. Doing what Rust does is now 2 years late, it would take 5 years to get there. Doing what C++ does, does not help. Why would I use D instead of C++ then?

Just pick a direction, because right now, the direction is not very clear and then progress becomes impossible. No direction, means no progress...

On 18/1/21 13:41, Ola Fosheim Grøstad wrote:
> Yes, it is natural that the current D population don't mind the current GC. Otherwise they would be gone... but then you have to factor in all the people that go through the revolving door and does not stay. If they stayed the eco system would be better. So the fact that they don't... is effecting everyone in a negative way (also those that har happy with the runtime).

I must be in the minority here because one of the reasons why I started using D was precisely because it HAS a GC with full support. I wouldn't even have considered it if it hadn't.

For what I usually do (non-critical server-side unattended processing) latency is most obviously not an issue, and I for me not having to worry about memory management and being able to focus on the task at hand is a requirement.

So I think that several key people (in the community) have different, sometimes even contradicting issues they feel very strongly about, and think these are the most important ones, or the ones that move most people.

This is quite OT (perhaps I should have split the topic), but I think that instead of focusing on what people dislike about D, it would help to ask people as well why they DID choose D.

In my case, I'm coming from a mostly Java (with a touch of C/C++) and was looking for:

* C/C++/Java-like syntax
* OOP support (sorry, I'm too used to that ;-) )
* Proper meta-programing / templates (without Java's generics / type erasure)
* Compiled language
* GC (IOW, no worries about memory management)
* Full linux support

On Monday, 18 January 2021 at 13:14:16 UTC, Arafel wrote:
> I must be in the minority here because one of the reasons why I started using D was precisely because it HAS a GC with full support. I wouldn't even have considered it if it hadn't.

You are probably not in a minority among those that use D for productive purposes, basically doing batch-like programming (or with similar requirements).

Nothing wrong with making that a focus, but then that would be a direction. There are other (growing) alternatives in that direction too...