On Saturday, 13 June 2020 at 16:30:54 UTC, James Lu wrote:
> 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.

Ostensibly, many have/had similar (wistful) thoughts, and I'm doubting whether this scenario will ever occur.

On Saturday, 13 June 2020 at 19:08:17 UTC, Paulo Pinto wrote:
> 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.

You are using a strawman argument, people that don't like GC for *systems* programming aren't against *all* GCs.

> 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.

That no one uses. C++/CLI is dead. C++/CX is dead. There's C++/WinRT which is dying and being replaced by Rust :). You are just giving reasons against a GC, no one liked using C++/CLI or C++/CX.

On Sunday, 14 June 2020 at 00:47:08 UTC, Avrina wrote:
> *systems* programming

See, this is another thing I wish we'd avoid. I prefer to call D "general purpose" (or maybe "all purpose") and avoid the poorly-defined "systems" label anyway. It more accurately describes D in the real world.

On Sunday, 14 June 2020 at 01:25:46 UTC, Adam D. Ruppe wrote:
> On Sunday, 14 June 2020 at 00:47:08 UTC, Avrina wrote:
>> *systems* programming
>
> See, this is another thing I wish we'd avoid. I prefer to call D "general purpose" (or maybe "all purpose") and avoid the poorly-defined "systems" label anyway. It more accurately describes D in the real world.

Go was in a similar spot several years ago. They first used the systems programming language in their marketing, but then people criticized them for having a GC. So they pivoted towards "systems as in web servers and stuff, not like operating systems".

On Sunday, 14 June 2020 at 12:17:58 UTC, JN wrote:
> On Sunday, 14 June 2020 at 01:25:46 UTC, Adam D. Ruppe wrote:
>> On Sunday, 14 June 2020 at 00:47:08 UTC, Avrina wrote:
>>> *systems* programming
>>
>> See, this is another thing I wish we'd avoid. I prefer to call D "general purpose" (or maybe "all purpose") and avoid the poorly-defined "systems" label anyway. It more accurately describes D in the real world.
>
> Go was in a similar spot several years ago. They first used the systems programming language in their marketing, but then people criticized them for having a GC. So they pivoted towards "systems as in web servers and stuff, not like operating systems".

One quote I like is "C is for control." That is a remarkably
good reflection of C and C++: control over performance, over details.
JavaScript has a powerful JIT that let's me get great performance.

But I can't control memory deallocation. I can't add RAII. I can't
control memory layout. Instead, I have to fidget with the limited
tools I do have.

Perhaps we could sell GC as "one of many tools in a disciplined
programmer's toolbox."

On Sunday, 14 June 2020 at 00:47:08 UTC, Avrina wrote:
> On Saturday, 13 June 2020 at 19:08:17 UTC, Paulo Pinto wrote:
>> 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.
>
> You are using a strawman argument, people that don't like GC for *systems* programming aren't against *all* GCs.
>
>> 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.
>
> That no one uses. C++/CLI is dead. C++/CX is dead. There's C++/WinRT which is dying and being replaced by Rust :). You are just giving reasons against a GC, no one liked using C++/CLI or C++/CX.

C++/CLI is so much dead that is was the major roadmap bullet point for getting .NET Core 3.0 out of the door.

Plenty of Windows developers love C++/CX, in fact the game is still out there regarding C++/WinRT adoption, and the only thing it going for it is the forced adoption via WinUI.

Which with Project Reunion's admission of UWP failure, it still remains to be seen if any major group of Windows developers actually cares about C++/WinRT, or will continue to use MFC and .NET Forms/WPF instead as always.

As for Rust replacing C++, C++/WinRT and Rust/WinRT are children of the same author, C++/WinRT still fails to match C++/CX tooling to this day, while Rust/WinRT barely left the design board.

On Sunday, 14 June 2020 at 12:17:58 UTC, JN wrote:
> On Sunday, 14 June 2020 at 01:25:46 UTC, Adam D. Ruppe wrote:
>> On Sunday, 14 June 2020 at 00:47:08 UTC, Avrina wrote:
>>> *systems* programming
>>
>> See, this is another thing I wish we'd avoid. I prefer to call D "general purpose" (or maybe "all purpose") and avoid the poorly-defined "systems" label anyway. It more accurately describes D in the real world.
>
> Go was in a similar spot several years ago. They first used the systems programming language in their marketing, but then people criticized them for having a GC. So they pivoted towards "systems as in web servers and stuff, not like operating systems".

Yet companies like F-Secure have a different opinion on that regard,

https://labs.f-secure.com/blog/tamago/

https://www.f-secure.com/en/consulting/foundry/usb-armory

I bet the D community would enjoy that USB Armory used bare metal D instead of Go.

Or that Google wouldn't be writing firmware in Go, regardless of what people consider systems programming to be, https://www.usenix.org/system/files/conference/atc15/atc15-paper-minnich.pdf

This is what D sometimes misses, don't try to please everyone, just keep charging despite the voices that tell that due to feature X it isn't applicable in domain Y and then changing the boat mid-course to please those voices.

On Sunday, 14 June 2020 at 01:25:46 UTC, Adam D. Ruppe wrote:
> On Sunday, 14 June 2020 at 00:47:08 UTC, Avrina wrote:
>> *systems* programming
>
> See, this is another thing I wish we'd avoid. I prefer to call D "general purpose" (or maybe "all purpose") and avoid the poorly-defined "systems" label anyway. It more accurately describes D in the real world.

I agree, but there's a reason why D is often compared with C/C++ and not C#. D has inherited quite a bit of nuisance from C and C++ that something like C# doesn't have. This was done so that C and C++ code could be copied and pasted into D.

On Sunday, 14 June 2020 at 15:28:55 UTC, James Lu wrote:
> On Sunday, 14 June 2020 at 12:17:58 UTC, JN wrote:
>> On Sunday, 14 June 2020 at 01:25:46 UTC, Adam D. Ruppe wrote:
>>> On Sunday, 14 June 2020 at 00:47:08 UTC, Avrina wrote:
>>>> *systems* programming
>>>
>>> See, this is another thing I wish we'd avoid. I prefer to call D "general purpose" (or maybe "all purpose") and avoid the poorly-defined "systems" label anyway. It more accurately describes D in the real world.
>>
>> Go was in a similar spot several years ago. They first used the systems programming language in their marketing, but then people criticized them for having a GC. So they pivoted towards "systems as in web servers and stuff, not like operating systems".
>
> 
> Perhaps we could ...

Ha ha. We could has been said here for yrs since I came around. That's sell never happens.

But first thing first, let's fix D issues first.

On Saturday, 13 June 2020 at 14:54:41 UTC, H. S. Teoh wrote:

> 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.)

For years I avoided D because it was marketed as an alternative implementation of C++ and I didn't want C++. Now apparently the only marketing of D is as an alternative Rust, and unlike C++, Rust is not horrible. That's not a battle D is going to win.

Programming languages are adopted to get work done. Starting a thread on HN where D is competing against Rust while Rust is setting the rules is not a substitute for showing people that they can do stuff in D.