www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Social media

reply James Lu <jamtlu gmail.com> writes:
A thread for documenting D's discussion on social media.
Jun 12 2020
parent reply James Lu <jamtlu gmail.com> writes:
"Ask HN: Why do you use Rust, when D is available?" 
https://news.ycombinator.com/item?id=23494490
Jun 12 2020
next sibling parent reply Clarice <cl ar.ice> writes:
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.
Jun 12 2020
next sibling parent aberba <karabutaworld gmail.com> writes:
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.


To convince some people about those valid points, you'll have to 
transplant for them a new brain. Or go back in time and change 
their life course.

More to the point, it'll be great to have those recurring issues 
documented. And visible to everyone one...including ongoing 
efforts.

I know not everyone thinks that way though.
Jun 13 2020
prev sibling parent reply James Lu <jamtlu gmail.com> writes:
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.
Jun 13 2020
parent Clarice <cl ar.ice> writes:
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.
Jun 13 2020
prev sibling parent reply IGotD- <nise nise.com> writes:
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.
Jun 13 2020
next sibling parent aberba <karabutaworld gmail.com> writes:
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.


GC depends on who you talk to.
Jun 13 2020
prev sibling next sibling parent reply JN <666total wp.pl> writes:
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".
Jun 13 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jun 13 2020
next sibling parent Avrina <avrina12309412342 gmail.com> writes:
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.
Jun 13 2020
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
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).
Jun 13 2020
next sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
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.
Jun 13 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
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.
Jun 13 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
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.
Jun 13 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jun 13 2020
next sibling parent reply JN <666total wp.pl> writes:
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".
Jun 14 2020
next sibling parent reply James Lu <jamtlu gmail.com> writes:
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."
Jun 14 2020
parent aberba <karabutaworld gmail.com> writes:
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.
Jun 14 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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.
Jun 14 2020
prev sibling parent Avrina <avrina12309412342 gmail.com> writes:
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 C++ code could be copied and pasted into D.
Jun 14 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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.
Jun 14 2020
prev sibling parent reply IGotD- <nise nise.com> writes:
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.
Jun 13 2020
parent Paulo Pinto <pjmlp progtools.org> writes:
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.
Jun 13 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jun 13 2020
parent reply bachmeier <no spam.net> writes:
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.
Jun 16 2020
parent Clarice <cl ar.ice> writes:
On Tuesday, 16 June 2020 at 21:06:47 UTC, bachmeier wrote:

 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.


I agree 100%. Also, advertising D anywhere doesn't seem to be 
worth the time and effort since it's either complaining/lamenting 
(A lot of it's inane but some is certainly justified.), or it's 
"hey, Rust|{popular lang} blah blah blah".
Jun 16 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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.
Jun 13 2020
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 13 June 2020 at 10:43:41 UTC, IGotD- wrote:

 Does this have anything to do with that swapping out GC 
 algorithms in Nim is much more easy than in D?


Is that true, though?


 In D you can't really swap GC algorithms by just changing a 
 compiler option.


Better yet, it doesn’t even need a reconciliation: just add 
“--DRT-gcopt=gc:precise” on the command line and you have changed 
the scanning algorithm. There are many more options to configure 
the gc[1]. You can even write your own collector and switching to 
it is just as simple.

— Bastiaan.

[1] https://dlang.org/spec/garbage.html#gc_config
Jun 13 2020
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
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.
Jun 13 2020
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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. :-)
Jun 13 2020