On Saturday, 13 June 2020 at 13:22:13 UTC, Bastiaan Veelo wrote:
> On Saturday, 13 June 2020 at 13:18:12 UTC, Bastiaan Veelo wrote:
>> Better yet, it doesn’t even need a reconciliation:
>
> s/reconciliation/recompilation
>
> My phone thinks it’s smarter than me.

I found reconciliation quite a good fit. :-)

On Saturday, 13 June 2020 at 13:11:20 UTC, Adam D. Ruppe wrote:
> On Saturday, 13 June 2020 at 13:00:35 UTC, JN wrote:
>> There is always someone saying that you don't have to use GC in D
>
> GC is a proven winner in real world industry programming and is one of D's strengths. Why we constantly shoot ourselves in the foot by conceding this ground to internet trolls is beyond me.

The GC in those languages isn't the same GC in D. There are drawbacks due to the choices it made. D tried to do everything at the same time, so it is a master of none. I don't think you can compare the success in other languages that fully embrace their GC being the same as with D.

On Saturday, 13 June 2020 at 13:11:20 UTC, Adam D. Ruppe wrote:
> On Saturday, 13 June 2020 at 13:00:35 UTC, JN wrote:
>> There is always someone saying that you don't have to use GC in D
>
> Yeah, this is true and for special cases we can show users how it is done, but I wish we'd just focus on actually selling GC instead of hiding from it.
>
> GC is a proven winner in real world industry programming and is one of D's strengths. Why we constantly shoot ourselves in the foot by conceding this ground to internet trolls is beyond me.

Indeed, even hard core C++ devs that happen to work with Unreal, UWP/COM or DriverKit have to make peace with GC technologies (either tracing or refcounted).

On Saturday, 13 June 2020 at 13:00:35 UTC, JN wrote:
> On Saturday, 13 June 2020 at 10:43:41 UTC, IGotD- wrote:
>> On Friday, 12 June 2020 at 19:45:20 UTC, James Lu wrote:
>>> "Ask HN: Why do you use Rust, when D is available?" https://news.ycombinator.com/item?id=23494490
>>
>> It's funny how GC is repeatedly mentioned as a drawback of D, however it is never mentioned as a drawback of Nim. Does this have anything to do with that swapping out GC algorithms in Nim is much more easy than in D? In D you can't really swap GC algorithms by just changing a compiler option.
>
> I think there are three factors (never used Nim):
>
> 1) [citation needed] but I think Nim is less popular than D, so it's below the radar. "There are only two kinds of languages: the ones people complain about and the ones nobody uses."
>
> 2) I think Nim attracts different types of programmers. Nim seems to me like a mix of Python and Pascal and it seems these kind of programmers are going towards it. D is openly courting C++ programmers and many C++ programmers have elitist attitudes towards GC.
>
> 3) I think Nim isn't really looking to offer any ways to avoid automatic memory management, be it ARC or GC. D is. "How do I manage memory in D?". There is always someone saying that you don't have to use GC in D, there's betterC, @nogc, allocators. Then someone always comes in to say half of standard library doesn't work and most dub packages expect GC. In Nim, it's like "how do I manage memory?", "oh, Nim handles that for you, enjoy your stay".

Not only Nim, if you do iOS you have to deal with reference counting GC, on Android tracing GC (very few use cases are allowed for NDK) and on Windows .NET and reference counting GC for COM/UWP.

And there are companies like PTC and Aicas selling real time JVMs for industrial deployments, and I bet they still do have enough customers.

So where D fails short is maybe trying to offer all models, without having a corporate overloard that drives the sheeps into the barn, even if they come screeming all the way into it.

On Sat, Jun 13, 2020 at 01:11:20PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Saturday, 13 June 2020 at 13:00:35 UTC, JN wrote:
> > There is always someone saying that you don't have to use GC in D
> 
> Yeah, this is true and for special cases we can show users how it is done, but I wish we'd just focus on actually selling GC instead of hiding from it.
> 
> GC is a proven winner in real world industry programming and is one of D's strengths. Why we constantly shoot ourselves in the foot by conceding this ground to internet trolls is beyond me.

+100!  For many applications, having a GC is not detrimental in any way, and in fact as you said, GC brings many benefits, like, for example, freeing up the programmers' energy to focus on the problem domain instead of incessantly thinking about memory management issues.  And frees up API design space to focus on the problem domain instead of being cluttered with endless nitty-gritties of memory management. There's a lot to be said for lean and clean APIs that maximize composability, as opposed to APIs where memory management paraphrenalia clutters every other corner.

Rather than shying away from GC, we shold be promoting it. @nogc is really for special niches, that really shouldn't be a huge concern for "normal" code.  (But good luck saying this to the C/C++ knee-jerk anti-GC crowd.)


T

-- 
Chance favours the prepared mind. -- Louis Pasteur

On Saturday, 13 June 2020 at 05:36:10 UTC, Clarice wrote:
> On Friday, 12 June 2020 at 19:45:20 UTC, James Lu wrote:
>> "Ask HN: Why do you use Rust, when D is available?" https://news.ycombinator.com/item?id=23494490
>
> That is some depressing stuff. And as usual, complaints about the GC rule the day along with some shallow commentary. (Typical HN) However, concerns about cross-platform IDE support and outdated std modules are certainly valid.

I'm hoping the "killer app" comes around. Personally, I feel a "killer app" might come when WASM gets a GC.

On Saturday, 13 June 2020 at 14:43:22 UTC, Paulo Pinto wrote:
> On Saturday, 13 June 2020 at 13:11:20 UTC, Adam D. Ruppe wrote:
>> On Saturday, 13 June 2020 at 13:00:35 UTC, JN wrote:
>>> There is always someone saying that you don't have to use GC in D
>>
>> Yeah, this is true and for special cases we can show users how it is done, but I wish we'd just focus on actually selling GC instead of hiding from it.
>>
>> GC is a proven winner in real world industry programming and is one of D's strengths. Why we constantly shoot ourselves in the foot by conceding this ground to internet trolls is beyond me.
>
> Indeed, even hard core C++ devs that happen to work with Unreal, UWP/COM or DriverKit have to make peace with GC technologies (either tracing or refcounted).

I've heard heard the Unreal argument before. That's not the same thing as a GC in a programming language. You wouldn't be able to build the GC built in Unreal in a GC only language. You are using it as an example to use the GC but in reality it demonstrates the need for programming languages that doesn't force you to use one.

On Saturday, 13 June 2020 at 14:43:22 UTC, Paulo Pinto wrote:
>
> Indeed, even hard core C++ devs that happen to work with Unreal, UWP/COM or DriverKit have to make peace with GC technologies (either tracing or refcounted).

I would suspect that many objects in Unreal engine or any game development kit are reference counted already. The reason is that game engines need to work in an SMP environment and there atomic reference counting suddenly makes a lot of sense. You don't want to free a resource while another CPU is working on it.

On Saturday, 13 June 2020 at 18:43:10 UTC, IGotD- wrote:
> On Saturday, 13 June 2020 at 14:43:22 UTC, Paulo Pinto wrote:
>>
>> Indeed, even hard core C++ devs that happen to work with Unreal, UWP/COM or DriverKit have to make peace with GC technologies (either tracing or refcounted).
>
> I would suspect that many objects in Unreal engine or any game development kit are reference counted already. The reason is that game engines need to work in an SMP environment and there atomic reference counting suddenly makes a lot of sense. You don't want to free a resource while another CPU is working on it.

Reference counting is a GC algorithm from CS point of view, regardless how the anti GC crown tries to sell it otherwise.

Also requires the same level of tracing GC optimization to avoid performance bottlenecks or stack overflows.

For example, in C++/WinRT there is background cleaning thread to take care of calling destructors when reference count reaches zero.

On Saturday, 13 June 2020 at 16:39:16 UTC, Avrina wrote:
> On Saturday, 13 June 2020 at 14:43:22 UTC, Paulo Pinto wrote:
>> On Saturday, 13 June 2020 at 13:11:20 UTC, Adam D. Ruppe wrote:
>>> On Saturday, 13 June 2020 at 13:00:35 UTC, JN wrote:
>>>> There is always someone saying that you don't have to use GC in D
>>>
>>> Yeah, this is true and for special cases we can show users how it is done, but I wish we'd just focus on actually selling GC instead of hiding from it.
>>>
>>> GC is a proven winner in real world industry programming and is one of D's strengths. Why we constantly shoot ourselves in the foot by conceding this ground to internet trolls is beyond me.
>>
>> Indeed, even hard core C++ devs that happen to work with Unreal, UWP/COM or DriverKit have to make peace with GC technologies (either tracing or refcounted).
>
> I've heard heard the Unreal argument before. That's not the same thing as a GC in a programming language. You wouldn't be able to build the GC built in Unreal in a GC only language. You are using it as an example to use the GC but in reality it demonstrates the need for programming languages that doesn't force you to use one.

Sure it is, Blueprints and Unreal C++ (as C++ dialect used in Unreal) have GC support.

And apparently everyone keeps forgetting that C++11 has gotten a GC API, while a couple of dialects like C++/CLI and C++/CX also have GC extensions.