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