www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D on quora ...

reply Rion <rion rio.com> writes:
https://www.quora.com/What-is-your-review-of-D-programming-language

It seems that D still has the GC being mentioned up to today.

Maybe its better to move the standard library slower to a non gc 
version in the future...
Oct 06
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via Digitalmars-d wrote:
 https://www.quora.com/What-is-your-review-of-D-programming-language
 
 It seems that D still has the GC being mentioned up to today.
 
 Maybe its better to move the standard library slower to a non gc
 version in the future...
Why is GC a problem? T -- Everybody talks about it, but nobody does anything about it! -- Mark Twain
Oct 06
next sibling parent reply Ali <fakeemail example.com> writes:
On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
 On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via 
 Digitalmars-d wrote:
 https://www.quora.com/What-is-your-review-of-D-programming-language
 
 It seems that D still has the GC being mentioned up to today.
 
 Maybe its better to move the standard library slower to a non 
 gc version in the future...
Why is GC a problem? T
The reputation is D's GC is slow, and Manual Memory Management is fast
Oct 06
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Oct 06, 2017 at 06:09:58PM +0000, Ali via Digitalmars-d wrote:
 On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
 On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via Digitalmars-d wrote:
 https://www.quora.com/What-is-your-review-of-D-programming-language
 
 It seems that D still has the GC being mentioned up to today.
 
 Maybe its better to move the standard library slower to a non gc
 version in the future...
Why is GC a problem? T
The reputation is D's GC is slow, and Manual Memory Management is fast
The first point is valid (when are we going to get a better GC? :-/), but the second is questionable. But there's not much you can say to GC-phobic C/C++ aficiandos to convince them otherwise. (I used to be one of them.) T -- Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
Oct 06
next sibling parent SrMordred <patric.dexheimer gmail.com> writes:
On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote:
 On Fri, Oct 06, 2017 at 06:09:58PM +0000, Ali via Digitalmars-d 
 wrote:
 On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
 On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via 
 Digitalmars-d wrote:
 https://www.quora.com/What-is-your-review-of-D-programming-language
 
 It seems that D still has the GC being mentioned up to 
 today.
 
 Maybe its better to move the standard library slower to a 
 non gc version in the future...
Why is GC a problem? T
The reputation is D's GC is slow, and Manual Memory Management is fast
The first point is valid (when are we going to get a better GC? :-/), but the second is questionable. But there's not much you can say to GC-phobic C/C++ aficiandos to convince them otherwise. (I used to be one of them.) T
For me the important point is not directly about performance, but about determinism. I know when the GC is called, and i can set when to collect, but I have no idea what they will do, how much memory they will free nor the time they will spent doing it. And this lack of control is the true problem.
Oct 06
prev sibling parent reply Jon Degenhardt <jond noreply.com> writes:
On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote:
 On Fri, Oct 06, 2017 at 06:09:58PM +0000, Ali via Digitalmars-d 
 wrote:
 The reputation is D's GC is slow, and Manual Memory Management 
 is fast
The first point is valid (when are we going to get a better GC? :-/), but the second is questionable.
Have there been studies quantifying the performance of D's GC relative to other GC implementations? My anecdotal experience is that D's GC can have undesirable latency behavior (long pauses), but throughput appears good. Of course, quantified metrics would be far preferable to anecdotal observations. --Jon
Oct 06
parent reply Laeeth Isharc <laeeth nospamlaeeth.com> writes:
On Saturday, 7 October 2017 at 01:00:41 UTC, Jon Degenhardt wrote:
 On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote:
 On Fri, Oct 06, 2017 at 06:09:58PM +0000, Ali via 
 Digitalmars-d wrote:
 The reputation is D's GC is slow, and Manual Memory 
 Management is fast
The first point is valid (when are we going to get a better GC? :-/), but the second is questionable.
Have there been studies quantifying the performance of D's GC relative to other GC implementations? My anecdotal experience is that D's GC can have undesirable latency behavior (long pauses), but throughput appears good. Of course, quantified metrics would be far preferable to anecdotal observations. --Jon
Have you tried running the GC instrumentation on your tsv utilities? That might make for a very interesting blog post.
Oct 06
parent Jon Degenhardt <jond noreply.com> writes:
On Saturday, 7 October 2017 at 03:15:41 UTC, Laeeth Isharc wrote:
 On Saturday, 7 October 2017 at 01:00:41 UTC, Jon Degenhardt 
 wrote:
 Have there been studies quantifying the performance of D's GC 
 relative to other GC implementations? My anecdotal experience 
 is that D's GC can have undesirable latency behavior (long 
 pauses), but throughput appears good. Of course, quantified 
 metrics would be far preferable to anecdotal observations.

 --Jon
Have you tried running the GC instrumentation on your tsv utilities? That might make for a very interesting blog post.
Well, I have for the tsv utilities and some other programs. That's what's behind my observations. While interesting, I don't think I have enough definitive data to draw conclusions for a blog post. Two specifics: (1) GC profile data shows long max pause times in several benchmarks. However, where it has occurs it's clearly associated with very large AAs. It may not be representative of more common use cases. (There is more quantification I could do here though.) (2) The benchmarks I've run are all on throughput oriented tasks. In these the D programs have compared well to other native compiled programs, mostly using manual memory management. I think this does say something to the effect that choosing good algorithms and memory use approaches is usually more important than the GC vs manual memory selection. And, it is consistent with a good throughput story for D's GC, but is hardly a direct comparison.
Oct 06
prev sibling parent reply Random D user <no email.com> writes:
On Friday, 6 October 2017 at 18:09:58 UTC, Ali wrote:
 On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
 On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via 
 Digitalmars-d wrote:
 https://www.quora.com/What-is-your-review-of-D-programming-language
 
 It seems that D still has the GC being mentioned up to today.
 
 Maybe its better to move the standard library slower to a non 
 gc version in the future...
Why is GC a problem? T
The reputation is D's GC is slow, and Manual Memory Management is fast
Actually, Manual Memory Management is slow and D's GC is slower. But IMO that kind of means GC isn't that big of a problem in D. Because, if malloc/free is slow (free is often slower), you want to avoid them as much as possible. You do this by reusing your memory/buffers. Which means that even if they are GC allocated buffers, they aren't collected and you are not allocating new buffers (often) after initial allocs, so the GC doesn't even run. There was a good talk in cppcon2016 that gives you an example what high perf AAA games do for memory allocation. The presenter explains how they reduced memory allocations from 300 000 to 3000 (https://youtu.be/tD4xRNB0M_Q?t=1200).
Oct 07
parent reply user1234 <user1234 12.ie> writes:
On Saturday, 7 October 2017 at 15:12:08 UTC, Random D user wrote:
 Actually, Manual Memory Management is slow and D's GC is slower.
Allocators should not work without an internal state. The fact that the heap chunk you get is mallocated or gcallocated shouldn't be a concern. The data structure can still use internal policies about how to request memory. At the same time with allocators it's another problem. I'd say that the old-fashioned strategies shouldn't slow down the growing, even if the memory provider is better. I don't know if you understand what i mean but in short: Appender!(SpecializedAllocator, int[]) shouldn't be slowest than Appender!(int[]) despite of the internal tweak that already exist. With allocators the situation is a bit confuse: who does provide the improvement ?
Oct 07
parent user1234 <user1234 12.ie> writes:
On Saturday, 7 October 2017 at 18:31:46 UTC, user1234 wrote:
 On Saturday, 7 October 2017 at 15:12:08 UTC, Random D user 
 wrote:
 Actually, Manual Memory Management is slow and D's GC is 
 slower.
Allocators should not work without an internal state.
Damn...I meant the opposite, Allocators should work without an internal state.
Oct 07
prev sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:

 Why is GC a problem?


 T
--
 **** Everybody talks about it, but nobody does anything about 
 it!  -- Mark Twain**
Are you sure your quotes are randomly generated ?? Jonathan Davis wrote: "We don't want D's standard library to rely on the GC when it doesn't need to, but there are language features that require it and really couldn't work with it, and there are cases where it's going to be involved by default for safety reasons." Perception is so important when people are making decisions about something they don't know. (As Walter says, you have to write tens of sloc in a language to really see it's benefits. They won't be so evident if you write D like the languages you know). So I think the GC series has been very helpful. But it might also be helpful to be very explicit on the functions that can and can't be called with nogc (I mean a top level overview in the docs) because it's one of the remaining sources of FUD that people say "yeah but you can't use large parts of the standard library without the GC". And for things that are useful and easiest done with GC it would be nice to have an alternative that doesn't depend on the GC - if for no other reason than to address objections. So the answer is then "yes - you're right, these X functions depend on the GC, but there are similar ones that don't". (Walter already started that for functions that use the GC for purely legacy reasons but I mean for more difficult cases too. I know Weka wrote their own versions of some std.algorithm functions for example). Many things aren't much work, but when you have a lot to do, even small frictions can have big consequences. So it's also a documentation question - it's not that easy from the outside last time I looked to see just how easy std.experimental.allocator is to use.
Oct 06
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/6/2017 1:39 PM, Laeeth Isharc wrote:
 Perception is so important when people are making decisions about something
they 
 don't know.  (As Walter says, you have to write tens of sloc in a language to 
 really see it's benefits.  They won't be so evident if you write D like the 
 languages you know).
I've nearly finished converting the Digital Mars C++ front end from C++ to D. Amusingly, it looks line-for-line almost identical to C++ (the biggest change being exchanging "->" for "."). But I deliberately made as few changes as possible, because if I introduce a bug doing that, it will be much easier to find by comparing the C++ source with the D source. To aid in this, I do it function-by-function, running the test suite after each function is converted. The idea is to use `git bisect` to isolate any conversion bugs not covered by the test suite. So the end result has all the flaws of the C++ version. But once in D, I can start taking advantage of D (like nested functions) to structurally improve it. It'll always show its C++ inheritance, though.
 So I think the GC series has been very helpful.
 
 But it might also be helpful to be very explicit on the functions that can and 
 can't be called with nogc (I mean a top level overview in the docs) because
it's 
 one of the remaining sources of FUD that people say "yeah but you can't use 
 large parts of the standard library without the GC".
 
 And for things that are useful and easiest done with GC it would be nice to
have 
 an alternative that doesn't depend on the GC - if for no other reason than to 
 address objections.  So the answer is then "yes - you're right, these X 
 functions depend on the GC, but there are similar ones that don't".  (Walter 
 already started that for functions that use the GC for purely legacy reasons
but 
 I mean for more difficult cases too.  I know Weka wrote their own versions of 
 some std.algorithm functions for example).  Many things aren't much work, but 
 when you have a lot to do, even small frictions can have big consequences.
 
 So it's also a documentation question - it's not that easy from the outside
last 
 time I looked to see just how easy std.experimental.allocator is to use.
One of the motivations for -betterC is to make D usable without any reliance whatsoever on the D runtime library, including the GC. You still get a long list of benefits from using D over C++. (The translation above is relying on -betterC.)
Oct 07
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, October 06, 2017 17:14:51 Rion via Digitalmars-d wrote:
 https://www.quora.com/What-is-your-review-of-D-programming-language

 It seems that D still has the GC being mentioned up to today.

 Maybe its better to move the standard library slower to a non gc
 version in the future...
D's GC isn't going anywhere. The implementation may be improved or replaced, but there are huge advantages to having the GC (particularly with regards to memory safety), and there _are_ actually times when using a GC is faster than something like reference counting. We don't want D's standard library to rely on the GC when it doesn't need to, but there are language features that require it and really couldn't work with it, and there are cases where it's going to be involved by default for safety reasons. For someone who wants to avoid the GC or minimize its use, there are things that they will need to do (e.g. you have to be careful with lambdas and probably use functors or functions, because closures are frequently needed when dealing with lambdas, and that means using the GC; nogc will catch those cases for you so that you know when a lambda isn't going to work). But while it should be possible for someone to avoid the GC if they need to, that does not mean that we're looking to get rid of it or even have not using it be the default. It just means that we don't want to force its use where that doesn't make sense. Honestly, I would _hate_ to use D without a GC. Without it, safe memory managament would not be possible, and you'd have to valgrind everything. As it stands, you only have to do that when you have sections of trusted code that would potentially be a problem. And there's a lot of code that's cleaner for not having to worry about managing memory. That's not to say that using the GC is always better or that other solutions are not more appropriate for some circumstances - and the fact that D gives you control over a lot of that is fantastic - but this idea that GCs are always nothing but bad and should be avoided by the plague is just nonsense. GCs have their pros and cons, but they can be fantastic, and idiomatic D programs actually mitigate a lot of the downsides that you can get with a GC, because they do so much with the stack rather than the heap (which is generally better performance-wise regardless of how heap allocations are managed). Yes, we could use a better GC, but overall, the GC is really just a PR problem and not a real one. Most programs can use it and be plenty performant. And those that can't have the tools necessary to minimize its use or even outright avoid it (though honestly, if someone is looking to outright avoid it, I'd lean towards wondering what the point of using D was in the first place; the proponents of the -betterc stuff still think that it's worth it though). Plenty of folks have managed to write performant programs that involve D's GC. - Jonathan M Davis
Oct 06
next sibling parent reply Rion <Rion rion.com> writes:
On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
 D's GC isn't going anywhere. The implementation may be improved 
 or replaced, but there are huge advantages to having the GC 
 (particularly with regards to memory safety), and there _are_ 
 actually times when using a GC is faster than something like 
 reference counting.

 We don't want D's standard library to rely on the GC when it 
 doesn't need to, but there are language features that require 
 it and really couldn't work with it, and there are cases where 
 it's going to be involved by default for  safety reasons. For 
 someone who wants to avoid the GC or minimize its use, there 
 are things that they will need to do (e.g. you have to be 
 careful with lambdas and probably use functors or functions, 
 because closures are frequently needed when dealing with 
 lambdas, and that means using the GC;  nogc will catch those 
 cases for you so that you know when a lambda isn't going to 
 work). But while it should be possible for someone to avoid the 
 GC if they need to, that does not mean that we're looking to 
 get rid of it or even have not using it be the default. It just 
 means that we don't want to force its use where that doesn't 
 make sense.

 Honestly, I would _hate_ to use D without a GC. Without it, 
  safe memory managament would not be possible, and you'd have 
 to valgrind everything. As it stands, you only have to do that 
 when you have sections of  trusted code that would potentially 
 be a problem. And there's a lot of code that's cleaner for not 
 having to worry about managing memory.

 That's not to say that using the GC is always better or that 
 other solutions are not more appropriate for some circumstances 
 - and the fact that D gives you control over a lot of that is 
 fantastic - but this idea that GCs are always nothing but bad 
 and should be avoided by the plague is just nonsense. GCs have 
 their pros and cons, but they can be fantastic, and idiomatic D 
 programs actually mitigate a lot of the downsides that you can 
 get with a GC, because they do so much with the stack rather 
 than the heap (which is generally better performance-wise 
 regardless of how heap allocations are managed).

 Yes, we could use a better GC, but overall, the GC is really 
 just a PR problem and not a real one. Most programs can use it 
 and be plenty performant. And those that can't have the tools 
 necessary to minimize its use or even outright avoid it (though 
 honestly, if someone is looking to outright avoid it, I'd lean 
 towards wondering what the point of using D was in the first 
 place; the proponents of the -betterc stuff still think that 
 it's worth it though). Plenty of folks have managed to write 
 performant programs that involve D's GC.

 - Jonathan M Davis
The issue is only mentioned, because it keeps getting talked about ( mostly one sided ) on forums and sites like the above mentioned quora.com. Its hard to change people there perception, without counter arguing. Currently as i write this, these claims on quora are unchallenged. I can make a few simple demos and have D use by default 5 to 10 more memory then the exact same C or C++ program. While D does not actually use it ( its only marked as allocated for the GC ), it does not dispel the notion or feeling of people that a GC = bad. Other aspects like being unsure when the GC will trigger can also influence people to a non-gc language. The Go developers have done a massive ( an impressive ) amount of work on trying to reduce GC pauses in the last two years, and that communication and effort has helped to reduce the GC myth ( for people looking at Go ). Another part of the issue is, while D can be run without the GC, i can not tell what parts of the standard library can work without the GC. Even a simple output parsing gave me a compile error when running nogc a while ago. When every new languages besides Rust or Zig are GC. That same "flaw" is not looked upon as a issue. It seems that D simply carries this GC stigma because the people mentioning are C++ developers, the same people D targets as a potential user base. D can have more success in targeting people from scripting languages like PHP, Ruby, Python, where the GC is not looked upon as a negative. The same effect can be seen in Go its popularity with drawing developers from scripting languages despite it not being there intention. I always felt that D position itself as a higher language and in turn scares people away while at the same time the people it wants to attracts, with most are already set in there ways and looking at excuses to discredit D. The whole C++ has all of D features and does not need a GC / GC is bad excuse we see in the quora.com posting fits that description ( and not only there, also on other sites ). If the GC issue can not be tackled and even with the recent communication blogs, it still keeps showing up. Is it maybe not better to focus the marketing features that other developers ( none C++ ) may see as advantages and slow draw then in? High performance web development package for instance. Vibe.d does not count because has not been seen giving any descent public performance in years ( like techempower or other sites ).
Oct 06
next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 6 October 2017 at 21:12:58 UTC, Rion wrote:
 I can make a few simple demos and have D use by default 5 to 10 
 more memory then the exact same C or C++ program. While D does 
 not actually use it ( its only marked as allocated for the GC 
 ), it does not dispel the notion or feeling of people that a GC 
 = bad.
You can configure the GC to deal with that [1].
 Other aspects like being unsure when the GC will trigger can 
 also influence people to a non-gc language.
In general: The GC can only trigger when you request memory from it. W.r.t to the current GC implementation, it will trigger when it doesn't have enough memory to fulfill an allocation request. In short: You're always in control of exactly when GC pauses can occur. I recommend the GC series for further information [1]. [1] https://dlang.org/spec/garbage.html#gc_config [2] https://dlang.org/blog/the-gc-series/
Oct 06
prev sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/6/17 14:12, Rion wrote:

[snip]

 When every new languages besides Rust or Zig are GC. That same "flaw" is
 not looked upon as a issue. It seems that D simply carries this GC
 stigma because the people mentioning are  C++ developers, the same
 people D targets as a potential user base.

 D can have more success in targeting people from scripting languages
 like PHP, Ruby, Python, where the GC is not looked upon as a negative.
 The same effect can be seen in Go its popularity with drawing developers
 from scripting languages despite it not being there intention.

 I always felt that D position itself as a higher language and in turn
 scares people away while at the same time the people it wants to
 attracts, with most are already set in there ways and looking at excuses
 to discredit D. The whole C++ has all of D features and does not need a
 GC / GC is bad excuse we see in the quora.com posting fits that
 description ( and not only there, also on other sites ).
What if we stop focusing on the C/C++ people so much? The like their tools and have no perceivable interest in moving away from them (Stockholm Syndrome much?). The arguments the use are primarily meant as defensive ploys, because they compare everything to C/C++ and when it doesn't match in some way or another the other language must be deficient. They've already decided that C/C++ is the meter stick against which all other languages are to be judged. Unsurprisingly, nothing that is NOT C/C++ meets their exacting demands. I saw we ditch the lot and focus on the large languages where D can get some traction (C#/Java). -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Oct 06
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote:
 What if we stop focusing on the C/C++ people so much? The like their 
 tools and have no perceivable interest in moving away from them 
 (Stockholm Syndrome much?). The arguments the use are primarily meant 
 as defensive ploys, because they compare everything to C/C++ and when 
 it doesn't match in some way or another the other language must be 
 deficient. They've already decided that C/C++ is the meter stick 
 against which all other languages are to be judged. Unsurprisingly, 
 nothing that is NOT C/C++ meets their exacting demands.

 I saw we ditch the lot and focus on the large languages where D can 
 get some traction (C#/Java).
Or recognize that painting huge diverse groups as if there's a single brush with which to do so is a huge fallacy.  Consider that the two leaders, as well as a large number of the contributing developers, come from the c++ community and that's not a bad thing, but rather a big part of _why_ they came to D. As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers.  Luckily, that's how things tend to proceed here, so yay for that.
Oct 06
parent reply AB <ab396356 users.sourceforge.net> writes:
On Saturday, 7 October 2017 at 06:19:01 UTC, Brad Roberts wrote:
 As always, focusing on the users of the language tends to pay a 
 lot more dividends than focusing on nay sayers.  Luckily, 
 that's how things tend to proceed here, so yay for that.
Feel free to ignore me then. I'll have to join this conversation as a naysayer: D is too little too late. It should have been competing with C++ since at least the early 90s. C++ should have **been** D. Do you know why I'm not using D right now? Because I'm already invested in C++. Also I can get a prebuilt C++14 compiler running on a Jurassic-dated FreeDOS; meanwhile you've abandoned Windows XP. Where D doesn't tread, C++ persists unchallenged. What will happen when Microsoft drops Windows 7, are you going to drop it too? So what can you do now, other than abandon all hope? You could standardize D ("ISO/IEC DLANG:2020"), officially endorse and support an "official" **standalone** IDE for it (so that it won't be a one-man two-user project), and cross your fingers hoping that C++ will run out of steam before D does. Or, you can continue talking about GC and call me a troll. In which case, I'll be under yonder bridge.
Oct 07
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/7/2017 1:16 AM, AB wrote:
 Do you know why I'm not using D right now? Because I'm already invested in
C++. 
 Also I can get a prebuilt C++14 compiler running on a Jurassic-dated FreeDOS;
DMC++ will still generate code for DOS, and I test it regularly. The compiler itself won't run on DOS, because DOS doesn't have enough memory. But as a cross compiler, it works fine. 16 bit C++, however, must be subsetted to work on 16 bits - exception handling and RTTI won't work (not enough memory). You can use a 32 bit DOS extender, though. I'm curious what C++14 compiler runs under DOS. The only C++ compilers I'm aware of that run under DOS are very old, pre-C++98, ones.
 meanwhile you've abandoned Windows XP.
dmd still works on and compiles for XP, it just officially is not supported on it. The problem with XP is its dodgy support for DLLs and thread local storage. This is an operating system problem. Officially, we want to support the entire language, not a subset.
 Where D doesn't tread, C++ persists 
 unchallenged. What will happen when Microsoft drops Windows 7, are you going
to 
 drop it too?
D compilers being Open Source means that anyone can support whatever platform they need to.
 So what can you do now, other than abandon all hope? You could standardize D 
 ("ISO/IEC DLANG:2020"), officially endorse and support an "official" 
 **standalone** IDE for it (so that it won't be a one-man two-user project),
and 
 cross your fingers hoping that C++ will run out of steam before D does.
D doesn't have to destroy C++ in order to be quite successful.
Oct 07
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, October 06, 2017 23:19:01 Brad Roberts via Digitalmars-d wrote:
 On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote:
 What if we stop focusing on the C/C++ people so much? The like their
 tools and have no perceivable interest in moving away from them
 (Stockholm Syndrome much?). The arguments the use are primarily meant
 as defensive ploys, because they compare everything to C/C++ and when
 it doesn't match in some way or another the other language must be
 deficient. They've already decided that C/C++ is the meter stick
 against which all other languages are to be judged. Unsurprisingly,
 nothing that is NOT C/C++ meets their exacting demands.

 I saw we ditch the lot and focus on the large languages where D can
 get some traction (C#/Java).
Or recognize that painting huge diverse groups as if there's a single brush with which to do so is a huge fallacy. Consider that the two leaders, as well as a large number of the contributing developers, come from the c++ community and that's not a bad thing, but rather a big part of _why_ they came to D. As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers. Luckily, that's how things tend to proceed here, so yay for that.
+1 Yeah, overall, most of the major contributors seem to have come from a C++ background, and a lot of the folks who actively comment do as well. We really don't seem to have any problem attracting folks from the C++ community. It's just that there are plenty of folks who would prefer to continue to use C++ or end up gravitating to a language that isn't C++ or D. But we still have plenty of C++ folks among those who decide to use D. Honestly, I've gotten to the point that I don't care much about trying to appeal to folks who complain about D. If we just make the language the best that we can, that will attract folks - that's largely what's attracted them in the past. Sure, we could and probably should do better with marketing D, and some of the complaints that get leveled at the language are valid and should be addressed, but trying to convince folks who are already convinced that they don't like D just doesn't seem like a good way to spend our time and energy. Complaints from folks not using D _can_ help shows us areas in which we're deficient, but they're not necessarily right, and they're not our actual user base. And really, what we need is a good language with good tools that supports a vibrant community of those who want to use it. We want that community to grow, because it will help the language and make it easier to get jobs using it, but it's not like we need to convince the whole world to use D - not to mention that there are classes of folks that we don't want; their views and goals just differ too much from ours, which is part of why having a diverse set of languages out there can actually be valuable. Different folks prefer different languages, and trying to get everyone to agree is never going to work. As long as D is sucessful enough that those of us who want to use it can use it and do what we need to get done, then that should be plenty. If more folks decide that they like what D's offering, then great. If they prefer C++ or C# or Rust or whatever, then they can have fun doing whatever they need to do with those languages, and we won't have to make changes to D just to make them happy. - Jonathan M Davis
Oct 07
prev sibling parent reply Ali <fakeemail example.com> writes:
On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
 D's GC isn't going anywhere.
Well, if I got the message correctly, it seems the key Dlang maintainers, are more sold on adding full support to Deterministic (manual) Memory management And a lot less sold on improving the existing GC So as I understand the current road map involve more work on Deterministic (manual) Memory management and a lot less work on improving the GC And the requirement for the GC will be removed from the standard library
Oct 06
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, October 06, 2017 21:39:21 Ali via Digitalmars-d wrote:
 On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
 D's GC isn't going anywhere.
Well, if I got the message correctly, it seems the key Dlang maintainers, are more sold on adding full support to Deterministic (manual) Memory management And a lot less sold on improving the existing GC So as I understand the current road map involve more work on Deterministic (manual) Memory management and a lot less work on improving the GC
There is definitely work being done towards improving more deterministic forms of memory management, but there's also been work done towards improving the GC. It just isn't talked about much. And even some of the more deterministic memory management is still potentially going to be using the GC (e.g. they've talked about introducing better language support for reference counting but using the GC to take care of cycles).
 And the requirement for the GC will be removed from the standard
 library
Some parts of the standard library will always require the GC. Much of it does not. The idea is to avoid requiring the GC when it doesn't make sense to require the GC, and there are cases where the GC is accidentally required. For instance, on the whole, stuff like std.algorithm should not use the GC and does not use the GC, but sometimes, when lambdas get involved, closures end up being allocated, which means that the GC gets used, and that may not have been intended or expected. Some of that can be prevented, and some of it can't. Someone who wants to fully avoid the GC probably will need to minimize passing lambdas to functions and prefer functions or functors. The main thing is that we need to ensure that the GC is not required when it's not meant to be required. It has never been the plan to remove it from Phobos completely. That really wouldn't make any sense, and in quite a few cases, it literally can't be done (e.g. a number of functions were designed to return newly allocated arrays; we can provide alternatives to them in a number of cases, but we couldn't make the existing stuff not use the GC). So, plenty of work still needs to be done to ensure that some stuff is marked nogc when it should be and ensure that the GC is not accidentally used, but we're not stripping out the GC. In some cases, it probably is just figuring out a way to make the documentation clearer like Laeeth mentioned, but that can be a bit entertaining given that whether something allocates is frequently a question of what arguments it's given (e.g. very little in std.algorithm will ever allocate if it's given a functor, but lots of it will allocate if it's given a lambda or non-static nested function that the compiler decides might need a closure allocated), and that can't really be covered by nogc in the documentation. You can use nogc when you call it to ensure that you're not triggering the GC, but it depends on what you passed, so it has to be inferred rather than being explicitly documented as nogc. And thus far, we really haven't done anything to figure out how to document when whether something uses the GC depends on what you pass it. Regardless, I can absolutely guarantee that Walter and Andrei are not planning to rip the GC out of everything. They just don't want to be requiring it when we don't need to, and that's not something that Phobos has always done a good job of, though a lot of the idioms it uses seriously reduce GC usage. - Jonathan M Davis
Oct 06
prev sibling next sibling parent Mengu <mengukagan gmail.com> writes:
On Friday, 6 October 2017 at 17:14:51 UTC, Rion wrote:
 https://www.quora.com/What-is-your-review-of-D-programming-language

 It seems that D still has the GC being mentioned up to today.

 Maybe its better to move the standard library slower to a non 
 gc version in the future...
as a d user, i do not give a single flying fuck about manual memory management. i love gc. period. please let gc be my guest and clean up everything for me. i have other problems like d / dmd / phobos failing me on freebsd; vibe.d working amazing on linux and throwing some random shit on freebsd. d is better than java, let alone c++. they both are crap. garbage. incredibly explicit and verbose. yet they get work done for other people. and these people, since the inception of d are throwing random arguments against d. they never ran out of arguments. it was two std libs, it was two d versions, it was lack of 3rd party libs, it was lack of giant corp support, it was lack of community / resources, it was and it will be something for those people. until they decide to shut the fuck up and actually give d a try. just like great people we get here everyday. a big problem of d is that it is a play-dough for many people here. they don't run into problems with d because they are mostly not eating their own dog food or incredible experts at d. (remember qtd guys?) if we have 100 wtf moments per hour, they probably have like 1-2 per year. they do more abstract stuff rather than concrete stuff. (atila & co, manu, sociomantic people, jacob and some more are exceptions). they are blind to newcomer problems. they also have prejudices like assuming you know all the low level stuff beforehand. when your beloved language (or its toolchain) screws things up for the app you wrote and deployed and will be used by millions of people per year, you have more problems than you imagined earlier and gc is not one of them.
Oct 06
prev sibling next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Friday, 6 October 2017 at 17:14:51 UTC, Rion wrote:
 https://www.quora.com/What-is-your-review-of-D-programming-language

 It seems that D still has the GC being mentioned up to today.

 Maybe its better to move the standard library slower to a non 
 gc version in the future...
WIP: https://github.com/libmir/mir-algorithm https://github.com/libmir/mir-random https://github.com/libmir/mir-cpuid
Oct 06
prev sibling parent Radu <void null.pt> writes:
On Friday, 6 October 2017 at 17:14:51 UTC, Rion wrote:
 https://www.quora.com/What-is-your-review-of-D-programming-language

 It seems that D still has the GC being mentioned up to today.

 Maybe its better to move the standard library slower to a non 
 gc version in the future...
I think there is some merit criticizing D's GC. The major problem with it ATM is that there is no convenient way to use all (most) of D's std lib without it. This also extends to third party libs - most of them are coded with the GC in mind because of the above point. I'm more an ambivalent person re. the GC - I see it as an useful tool most of the times, but also would like to get rid of it cleanly when circumstances require it. I think there are some great steps already done to make it easier for programmers to use D without the GC: nogc, betterC and the gang, but D is not yet up there. Not for the naysayers sake - there will always be plenty of them regardless, I think more focused work on finishing the bellow points will make pragmatic D programmers more productive: - Scope (-dip1000), a great tool to help code safe manual memory managed style apps. This could be huge for attracting more system level guys to D once it is finished (see bugzilla), it could offer some of Rust's guarantees without resorting to mind bending techniques - all in a nice C like syntax. - betterC, this one is nice as it enforces "cost free abstractions" bondage while providing a low level C compatibility, more work here on RAII will be a boost! In general the work done for betterC for reducing bloat and impose a "pay-as-you-go" discipline will help D in general. - Allocators - right now they are in Phobos... This is not great, they should be split in 2 parts: core an druntime. One should be able to use a minimal set in betterC mode, and the full version with druntime (all GC related parts). All the above are cascading on each other, and the sum will create a hard to refuse offer even for the most dye-hard C/C++ guys. And lastly, Ds GC needs work - it is not yet optimally implemented (see http://forum.dlang.org/thread/ewdoqmvslcnypzyrbfwz forum.dlang.org) not to mention that design wise there are still more things to explore and experiment with: precision scanning, determinism, and a lot of research done on system-level GCs yet to consider.
Oct 07