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
next sibling 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 Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= 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.
Well, no, deterministic memory management isn't slow. One specific implementation with a high level of naiveté might be slow. C is not a very clever language, it was designed to be minimal and with minimal compiler requirements and with most features pushed onto libraries, including memory management. C++ is just meta-level dressing over C…
 Because, if malloc/free is slow (free is often slower), you 
 want to avoid them as much as possible.
A naive generic library implementation that is used randomly will not be fast, but a more dedicated implementation for the program at hand could be very performant.
 You do this by reusing your memory/buffers.
Yes, in C/C++ you either have to resort to creating your own allocator in your program or you could used dedicated allocators. Or you just make them static global. Anyway, D doesn't improve on C/C++ when it comes to allocators. And it's garbage collector is pretty much stuck in the standard GC implementation from 1960s/1970s in terms of performance and features. Just because C/C++ is primitive doesn't mean that D is doing well, but at this point there is not much hope of D becoming a significant improvement on C++… So maybe it is better for D to stay where it is as there is basically very little support among the designers from improving the language semantics. In the C++ environment there is at least some movement, so maybe it will become a decent language in 2050, although they are stuck with the primitive C-foundation…
Oct 11
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 next 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
next sibling 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 next sibling parent reply Jerry <hurricane hereiam.com> 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.
Doesn't feel like that when the views of the people in charge don't align with what people are saying. I can understand people's dissatisfaction with Windows, but some people take it too far. The compiler for Windows is built using 32-bit, not only is the 64-bit version not built it's not even supported or tested. I think someone made a post a little while ago about LDC that 95% or more of downloads for their compiler were for the 64-bit version. If only one version is to be supported then it should be the 64-bit version. I can't even imagine the outrage there would be if 64-bit wasn't supported on Linux. Hell, they haven't even bothered setting up AppVeyor for dmd, free testing on Windows. Niche within a niche, can't expect much I guess.
Oct 07
parent reply Laeeth Isharc <laeeth nospamlaeeth.com> writes:
On Sunday, 8 October 2017 at 04:23:50 UTC, Jerry wrote:
 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.
Doesn't feel like that when the views of the people in charge don't align with what people are saying. I can understand people's dissatisfaction with Windows, but some people take it too far. The compiler for Windows is built using 32-bit, not only is the 64-bit version not built it's not even supported or tested. I think someone made a post a little while ago about LDC that 95% or more of downloads for their compiler were for the 64-bit version. If only one version is to be supported then it should be the 64-bit version. I can't even imagine the outrage there would be if 64-bit wasn't supported on Linux. Hell, they haven't even bothered setting up AppVeyor for dmd, free testing on Windows. Niche within a niche, can't expect much I guess.
You know it's not that hard to be the change you wish to see in the world. That's really the whole point of open source, or at least of at least reasonably or more free software - you're not at the mercy of a paid vendor to whom you pay a fortune for the favour of them closing or otherwise creatively ignoring your tickets. You can pretty easily fix many problems and irritations yourself, and if you're too busy then one can pay someone to do it, and if one is busy and has no money to spend right now one can try to persuade someone to work on it. But if one just grumbles, probably the result will be just what anyone would expect. 64 bit command line build didn't seem to work for a while. That's been fixed recently, as I recall. One can't really compare Linux and Windows 32 and 64 bit. Those worlds work very differently. Windows is as it is because they are fanatical about maintaining backwards compatibility. So unless you run out of memory then 32 bit compiler isn't much of a restriction. And if you are doing so much ctfe that you run out of memory, chances are you can figure out how to build the 64 bit compiler on Windows! Try using digger - might work now that the 64 bit command line build works again. And failing that maybe file a request on bugzilla. And I don't know but I guess if you contribute something to the D Foundation, probably - because it's still quite new - it will be easier to get people to listen to a gentle request to have a downloadable 64 bit compiler. These things do cost money, and right now I think somebody is paying for that out of the goodness of their heart...
Oct 11
parent Jerry <hurricane hereiam.com> writes:
On Wednesday, 11 October 2017 at 07:33:26 UTC, Laeeth Isharc 
wrote:
 You know it's not that hard to be the change you wish to see in 
 the world.  That's really the whole point of open source, or at 
 least of at least reasonably or more free software - you're not 
 at the mercy of a paid vendor to whom you pay a fortune for the 
 favour of them closing or otherwise creatively ignoring your 
 tickets.  You can pretty easily fix many problems and 
 irritations yourself, and if you're too busy then one can pay 
 someone to do it, and if one is busy and has no money to spend 
 right now one can try to persuade someone to work on it. But if 
 one just grumbles, probably the result will be just what anyone 
 would expect.
You still are at the mercy of the people maintaining the project. Which is kind of no different than being at the mercy of a big company from my experience. Some people listen, but a lot of the time they don't if something contradicts their views (having to do anything regarding Windows in this case). I could fork it and then maintain things myself, but that means fixing any pull requests or changes in the future yourself. Which now becomes a full time job, where as using the project to begin with was the point of reducing the workload, not increasing it.
 64 bit command line build didn't seem to work for a while.  
 That's been fixed recently, as I recall.  One can't really 
 compare Linux and Windows 32 and 64 bit.  Those worlds work 
 very differently.  Windows is as it is because they are 
 fanatical about maintaining backwards compatibility.  So unless 
 you run out of memory then 32 bit compiler isn't much of a 
 restriction.  And if you are doing so much ctfe that you run 
 out of memory, chances are you can figure out how to build the 
 64 bit compiler on Windows!
You can easily run out of memory, DMD is a memory hog. Yes that's exactly the problem I run into all the time. It's not even the amount of CTFE you are doing, you can run out of memory by doing something really simple. DMD is just horribly optimized in terms of memory. Yes more work for me when it's something that should be done as part of the build process.
 Try using digger - might work now that the 64 bit command line 
 build works again.  And failing that maybe file a request on 
 bugzilla.
For what... ?
 And I don't know but I guess if you contribute something to the 
 D Foundation, probably - because it's still quite new - it will 
 be easier to get people to listen to a gentle request to have a 
 downloadable 64 bit compiler.  These things do cost money, and 
 right now I think somebody is paying for that out of the 
 goodness of their heart...
Everything costs money. That's how the world works. If you mean hosting the source code. Well Github hosts the source for open source projects for free. If you mean distributing binaries, well Github allows you to upload binary files for people to download for free as well. If you mean testing, well there are a lot of alternatives that provide free testing for open source projects (like appveyor which isn't currently being used). If you mean this forum board? Well there are a lot of places you have a board for free. There's some 100+ pull requests in DMD alone, just trying to contribute something is a chore in itself. Making a contribution isn't really worth much.
Oct 11
prev sibling parent Adam Wilson <flyboynw gmail.com> writes:
On 10/6/17 23:19, Brad Roberts 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.
I'll admit the last sentence was an error. However, my main point is that we really need to stop worrying about other languages, and specifically C/C++. That horse has been beat to death. I enjoy using D and find it superior for many types of project. That's good enough for me. :) -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Oct 14
prev sibling next sibling parent reply 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
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.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.
Yes - as Andrei said in a talk, people are looking for an excuse not to have to take the time to learn something new. There's an inordinate strength of feeling in discussions in relation to D. If it's not your cup of tea, why do you care so much? The raising of spurious objections is much better than indifference at this point, and you can see this year that there has been a shift. People got downvoted for repeating the same old talking points that are now demonstrably not correct, whereas before it was a matter of judgement and people could reasonably differ.
 On Friday, October 06, 2017 23:19:01 Brad Roberts via
 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.
Long tail. We really couldn't care less about what most people think. In fact it's good that most people won't try D because what they will be expecting isn't yet what we offer (glossiness and hand-holding). At any one time there is a proportion of people who are unhappy with their existing choices and looking for something better. It's easy to grow in the early days - you don't need to appeal to most programmers. You just need to have a slightly stronger appeal to those who are already predisposed to like you (and to those who are already using your language and would like to use it for more things). And people conceive of the market in too small a way. People talk as if languages are in a battle to the death with each other - D can't succeed because it's too late, or because Rust has momentum. But the world is a very big place, and the set of people who talk much to a broad audience about what they are doing is a small one and thinking it reflects reality leads to distorted perceptions. Who would have thought that probably one of the larger code bases (500k SLOC) to be rewritten/converted in D might come from Pascal, with D competing with ADA? I don't know what has been decided there, but whatever the outcome, that's highly interesting, because it's probably true of others. Similarly Weka came from nowhere. A random tweet by Fowler led to them building their entire company on a language the founders hadn't used before. Because D is a highly ambitious language that isn't confined to a single domain, and that's a potential replacement in some domains for many other languages, most people won't know anyone who uses D because use is much more spread out. Enterprise users outside of web + big tech/startups don't talk about their choices that much. Microsoft didn't send out a press release when they used D in their COM team, for example - someone there just figured it was a good tool for the job and got on with it. Similarly the company that Andy Smith worked for (a money management company) didn't say anything, and it only happened that he talked about it because I suggested it and he happened to have time. Inordinately at this point in its development D is going to appeal to principals over agents, to people who have at least local authority to make decisions and don't have to persuade others, because the dynamics of how you persuade a committee are based on quite different things than making a decision and living or dying by how it turns out. That's okay. If people don't feel they can use D at work, they shouldn't. Some people will be able to, and as they have some success with it, others will start to imitate them. And in the meantime maybe it will be an advantage of sorts for the earlier adopters. It matters who your customers are, because that shapes what you become. And it's better early on to have people who make decisions on technical merits and who have the authority to do so, then to have a representative enterprise buyer! On Saturday, 7 October 2017 at 08:36:01 UTC, Jonathan M Davis wrote:
 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.
I agree with both parts. It doesn't do any harm to continue to work on getting the language's merits across. There's no point entirely hiding our light under a bushel. But doing good work and making the language and ecosystem better is by far more important because that's what matters and we're in a time when people will eventually get it even if they don't all currently.
 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.
Yes. (I'd put the emphasis on _help_)
 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
People seem to think language decisions are only about technical questions. But they're as much about values, and you're never going to get people to agree about values because people are facing different problems and are themselves different kinds of people. https://vimeo.com/230142234 Bryan Cantrill of Joyent nails it
  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
In a polyglot environment, D's code generation and introspection abilities might be quite valuable if it allows you to write core building blocks once and call them from other languages without too much boilerplate and bloat. One could use SWIG, but...
Oct 07
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 7 October 2017 at 21:08:42 UTC, Laeeth Isharc wrote:
 Who would have thought that probably one of the larger code 
 bases (500k SLOC) to be rewritten/converted in D might come 
 from Pascal, with D competing with ADA?  I don't know what has 
 been decided there, but whatever the outcome, that's highly 
 interesting, because it's probably true of others.
Nothing has been decided yet. More work needs to be done in determining where we can push the compatibility boundary. I was looking for ways to maintain binary compatibility with our existing datastructures and file formats, when my attention was needed for another big assignment. Our research into languages has been on hold since then. I hope to make some progress this winter. It is going to take time though, this is a task full of interesting challenges. But I am convinced that if we can find a way to translate to D, it will be an important move for the future of our company. Bastiaan.
Oct 07
prev sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/7/17 14:08, Laeeth Isharc 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.
Yes - as Andrei said in a talk, people are looking for an excuse not to have to take the time to learn something new. There's an inordinate strength of feeling in discussions in relation to D. If it's not your cup of tea, why do you care so much? The raising of spurious objections is much better than indifference at this point, and you can see this year that there has been a shift. People got downvoted for repeating the same old talking points that are now demonstrably not correct, whereas before it was a matter of judgement and people could reasonably differ.
 On Friday, October 06, 2017 23:19:01 Brad Roberts via
 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.
Long tail. We really couldn't care less about what most people think. In fact it's good that most people won't try D because what they will be expecting isn't yet what we offer (glossiness and hand-holding). At any one time there is a proportion of people who are unhappy with their existing choices and looking for something better. It's easy to grow in the early days - you don't need to appeal to most programmers. You just need to have a slightly stronger appeal to those who are already predisposed to like you (and to those who are already using your language and would like to use it for more things). And people conceive of the market in too small a way. People talk as if languages are in a battle to the death with each other - D can't succeed because it's too late, or because Rust has momentum. But the world is a very big place, and the set of people who talk much to a broad audience about what they are doing is a small one and thinking it reflects reality leads to distorted perceptions. Who would have thought that probably one of the larger code bases (500k SLOC) to be rewritten/converted in D might come from Pascal, with D competing with ADA? I don't know what has been decided there, but whatever the outcome, that's highly interesting, because it's probably true of others. Similarly Weka came from nowhere. A random tweet by Fowler led to them building their entire company on a language the founders hadn't used before. Because D is a highly ambitious language that isn't confined to a single domain, and that's a potential replacement in some domains for many other languages, most people won't know anyone who uses D because use is much more spread out. Enterprise users outside of web + big tech/startups don't talk about their choices that much. Microsoft didn't send out a press release when they used D in their COM team, for example - someone there just figured it was a good tool for the job and got on with it. Similarly the company that Andy Smith worked for (a money management company) didn't say anything, and it only happened that he talked about it because I suggested it and he happened to have time. Inordinately at this point in its development D is going to appeal to principals over agents, to people who have at least local authority to make decisions and don't have to persuade others, because the dynamics of how you persuade a committee are based on quite different things than making a decision and living or dying by how it turns out. That's okay. If people don't feel they can use D at work, they shouldn't. Some people will be able to, and as they have some success with it, others will start to imitate them. And in the meantime maybe it will be an advantage of sorts for the earlier adopters. It matters who your customers are, because that shapes what you become. And it's better early on to have people who make decisions on technical merits and who have the authority to do so, then to have a representative enterprise buyer! On Saturday, 7 October 2017 at 08:36:01 UTC, Jonathan M Davis wrote:
 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.
I agree with both parts. It doesn't do any harm to continue to work on getting the language's merits across. There's no point entirely hiding our light under a bushel. But doing good work and making the language and ecosystem better is by far more important because that's what matters and we're in a time when people will eventually get it even if they don't all currently.
 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.
Yes. (I'd put the emphasis on _help_)
 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
People seem to think language decisions are only about technical questions. But they're as much about values, and you're never going to get people to agree about values because people are facing different problems and are themselves different kinds of people. https://vimeo.com/230142234 Bryan Cantrill of Joyent nails it
  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
In a polyglot environment, D's code generation and introspection abilities might be quite valuable if it allows you to write core building blocks once and call them from other languages without too much boilerplate and bloat. One could use SWIG, but...
Oh dear, I seem to have accidentally set off a firestorm. Personally, I think there are better places to focus our energy than worrying about what the users of other languages think. We like D, that should be enough for us. The last line was somewhat tongue-in-cheek. There is no way we're going to convert C#/Java users either, and unlike C/C++ we cannot easily inter-operate with them. I like D because I get a language that feels comfortably similar to C#/Java, than adds a bunch of really useful tools on top of it, and is natively compiled. Instead of worrying about how to get more people to come from a specific language. People will come if they see an advantage in D so lets try to provide as many advantages as possible. :) -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Oct 14
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Saturday, 14 October 2017 at 22:43:33 UTC, Adam Wilson wrote:
 On 10/7/17 14:08, Laeeth Isharc wrote:
 In a polyglot environment, D's code generation and 
 introspection
 abilities might be quite valuable if it allows you to write 
 core
 building blocks once and call them from other languages 
 without too much
 boilerplate and bloat.  One could use SWIG, but...
Oh dear, I seem to have accidentally set off a firestorm. Personally, I think there are better places to focus our energy than worrying about what the users of other languages think. We like D, that should be enough for us. The last line was somewhat tongue-in-cheek. There is no way we're going to convert C#/Java users either, and unlike C/C++ we cannot easily inter-operate with them.
If we can convert Pascal users, why won't some C# and Java programmers be receptive to D? Plenty of people have approached D from Java: https://dlang.org/blog/2017/09/06/the-evolution-of-the-accessors-library/ https://dlang.org/blog/2017/08/11/on-tilix-and-d-an-interview-with-gerald-nunn/ https://github.com/intellij-dlanguage/intellij-dlanguage/ (Kingsley came from Java). Why can't we easily interop with Java and C#? I didn't find interop with Java so bad for what I was doing (embedding a Java library via the JVM with callbacks to D code), and Andy Smith found similar. http://dconf.org/2015/talks/smith.pdf (towards the end) C# interop for what I am doing sees easy enough. (I will generate C# wrappers for D structs and functions/methods). This work wasn't open-sourced, and nor did Microsoft send out a press release about their use of D in the COM team. But I spoke to the author in Berlin (maybe you did too), and it wasn't so much work to make it useful: http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf
 Instead of worrying about how to get more people to come from a 
 specific language. People will come if they see an advantage in 
 D so lets try to provide as many advantages as possible. :)
Yes - agree with this.
Oct 15
parent Adam Wilson <flyboynw gmail.com> writes:
On 10/15/17 13:40, Laeeth Isharc wrote:
 On Saturday, 14 October 2017 at 22:43:33 UTC, Adam Wilson wrote:
 On 10/7/17 14:08, Laeeth Isharc wrote:
 In a polyglot environment, D's code generation and introspection
 abilities might be quite valuable if it allows you to write core
 building blocks once and call them from other languages without too much
 boilerplate and bloat.  One could use SWIG, but...
Oh dear, I seem to have accidentally set off a firestorm. Personally, I think there are better places to focus our energy than worrying about what the users of other languages think. We like D, that should be enough for us. The last line was somewhat tongue-in-cheek. There is no way we're going to convert C#/Java users either, and unlike C/C++ we cannot easily inter-operate with them.
If we can convert Pascal users, why won't some C# and Java programmers be receptive to D? Plenty of people have approached D from Java:
Indeed. I am an example of just such a convert (from C#). :) But it is much more difficult to inter-operate. The easiest path that I can see is Micro-services. Hide your different languages behind a REST API, such that your components are not talking C#<->D anymore, but HTTP<->HTTP. Then the language matters a LOT less, then you can convert individual services to a new language whenever business needs dictate.
 https://dlang.org/blog/2017/09/06/the-evolution-of-the-accessors-library/
 https://dlang.org/blog/2017/08/11/on-tilix-and-d-an-interview-with-gerald-nunn/

 https://github.com/intellij-dlanguage/intellij-dlanguage/
 (Kingsley came from Java).

 Why can't we easily interop with Java and C#?  I didn't find interop
 with Java so bad for what I was doing (embedding a Java library via the
 JVM with callbacks to D code), and Andy Smith found similar.

 http://dconf.org/2015/talks/smith.pdf
 (towards the end)

 C# interop for what I am doing sees easy enough.  (I will generate C#
 wrappers for D structs and functions/methods).

 This work wasn't open-sourced, and nor did Microsoft send out a press
 release about their use of D in the COM team.  But I spoke to the author
 in Berlin (maybe you did too), and it wasn't so much work to make it
 useful:

 http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf
Very cool. I had no idea MSFT was doing that. I didn't talk to him, but I was fighting a bad cold at DConf this year. :( I avoided talking to a lot of people. Even so, I was more commenting on the fact that D has built in support for inter-operating with C/C++. It's not that it's impossible to inter-operate with C#/Java/etc., but it is significantly more work. And that can be a significant barrier to conversion when the ecosystem they are coming from comfortably provides everything they need already. :)
 Instead of worrying about how to get more people to come from a
 specific language. People will come if they see an advantage in D so
 lets try to provide as many advantages as possible. :)
Yes - agree with this.
-- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Oct 16
prev sibling parent qznc <qznc web.de> writes:
On Saturday, 7 October 2017 at 05:19:21 UTC, Adam Wilson wrote:
 I saw we ditch the lot and focus on the large languages where D 
 can get some traction (C#/Java).
I don't see a chance to attack C# unless Microsoft officially adopts D. Java is facing some uncertainty at the moment. The Java 9 module feature (Jigsaw) was forced against community/committee consensus. Oracle seems to let go (See EE4J). Java people are fine with GC, but really care for their IDE and D is lacking there. With respect to GC, I consider performance a red herring. Everybody who really cares for performance has enough possibilities in D to achieve it. My short answer wrt D and GC is "It is not really an issue" which admittedly does not sound very convincing. There is a long answer which is basically the article series in the D blog and I believe it is convincing enough. People looking for a short convincing answer are just chasing some hype, ignore them. I see opportunities for D in the web backend world. Microservices and serverless architectures make it (relatively) easy to introduce new languages. D needs more framework stuff for "easy and quick" microservices. D needs better IDE support, for example in hipster editors like VSCode. I see opportunities for D in the embedded world. The people who try to use Java for embedded would be served very well with D. Crosscompiling and architecture support needs improvement though. I recently heard some praise for Go, which allegedly makes it easier than C or Rust. I'm not sure about performance critical stuff. Maybe marketing C++-integration more could be helpful to get the people who rely on stuff like OpenCV, are forced to use C++ and dream about something better. We are fighting the C++ renaissance cool-aid, though. C++21 will surely solve all problems...
Oct 07
prev sibling next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 October 2017 at 21:12:58 UTC, Rion wrote:
 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 ).
+1 But you are losing your time trying to convince D's management that targeting C++ developers instead of scripters is a marketing error. For instance, I AM a C++ developer, and I use D EXCLUSIVELY for SCRIPTING tasks. Nothing else. And if you had asked me why I use D then, I would have answered : it's because it's faster and more effective than JavaScript/Node.js, Python and Ruby for these tasks. GC IS NOT A PROBLEM for scripting. We don't care about that. GC IS NEEDED for scripting languages. But as a C++ developer, I can tell you that : D's GC is what prevents me to use it for my current C++ programming tasks. Because I can perfectly live with a GC that progressively collects bits of memory in a predefined amount of time, like in the Nim language, but not one that can pause my application for an unpredictable amount of time. That's just my personal case and opinion, but I don't think I'm the only C++ programmer on the planet to dislike D's GC for typical C++ development cases, which are generally those where the lack of a GC is the reason that lead to the use of C++.
Oct 15
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 15 October 2017 at 07:21:55 UTC, Ecstatic Coder wrote:
 But as a C++ developer, I can tell you that : D's GC is what 
 prevents me to use it for my current C++ programming tasks.

 Because I can perfectly live with a GC that progressively 
 collects bits of memory in a predefined amount of time, like in 
 the Nim language, but not one that can pause my application for 
 an unpredictable amount of time.

 That's just my personal case and opinion, but I don't think I'm 
 the only C++ programmer on the planet to dislike D's GC for 
 typical C++ development cases, which are generally those where 
 the lack of a GC is the reason that lead to the use of C++.
Out of curiosity, what is it that stops you keeping the heap small and allocating memory manually for the rest?
Oct 15
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 15 October 2017 at 20:42:36 UTC, Laeeth Isharc wrote:
 On Sunday, 15 October 2017 at 07:21:55 UTC, Ecstatic Coder 
 wrote:
 But as a C++ developer, I can tell you that : D's GC is what 
 prevents me to use it for my current C++ programming tasks.

 Because I can perfectly live with a GC that progressively 
 collects bits of memory in a predefined amount of time, like 
 in the Nim language, but not one that can pause my application 
 for an unpredictable amount of time.

 That's just my personal case and opinion, but I don't think 
 I'm the only C++ programmer on the planet to dislike D's GC 
 for typical C++ development cases, which are generally those 
 where the lack of a GC is the reason that lead to the use of 
 C++.
Out of curiosity, what is it that stops you keeping the heap small and allocating memory manually for the rest?
In D I've the added complexity in trying to use the game engine (cocos2dx, unreal, cryengine) C++ libraries from D. So that's not worth the effort, if I can't use D's powerful standard library as usual. I don't like the idea that any hidden object allocation or string concatenation can trigger a GC for an undefined amount of time. In C++ you also have plenty of objects constructors/destructors called everywhere in your back, but none of them will ever trigger a GC...
Oct 16
parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 16 October 2017 at 09:58:46 UTC, Ecstatic Coder wrote:
 On Sunday, 15 October 2017 at 20:42:36 UTC, Laeeth Isharc wrote:
 On Sunday, 15 October 2017 at 07:21:55 UTC, Ecstatic Coder 
 wrote:
 [...]
Out of curiosity, what is it that stops you keeping the heap small and allocating memory manually for the rest?
In D I've the added complexity in trying to use the game engine (cocos2dx, unreal, cryengine) C++ libraries from D. So that's not worth the effort, if I can't use D's powerful standard library as usual. I don't like the idea that any hidden object allocation or string concatenation can trigger a GC for an undefined amount of time. In C++ you also have plenty of objects constructors/destructors called everywhere in your back, but none of them will ever trigger a GC...
A std::shared_ptr going out of scope can pause the program for just as long as a GC mark-and-sweep. Have you tried using a nogc main loop in your programs/games? I'm curious to learn why that might not have worked for you. Atila
Oct 16
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
 A std::shared_ptr going out of scope can pause the program for 
 just as long as a GC mark-and-sweep.
I don't use shared_ptr much, but why would a single shared_ptr be that slow?
Oct 16
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 16 October 2017 at 14:14:50 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
 A std::shared_ptr going out of scope can pause the program for 
 just as long as a GC mark-and-sweep.
I don't use shared_ptr much, but why would a single shared_ptr be that slow?
Cascade deletion of nested data structures, with the possibility of causing stack overflow. Nicely presented by Herb Sutter on his CppCon 2016 talk, "Leak-Freedom in C++... By Default.", which presented a GC like implementation for C++, using deferred pointer. https://www.youtube.com/watch?v=JfmTagWcqoE
Oct 16
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 16 October 2017 at 14:24:57 UTC, Paulo Pinto wrote:
 On Monday, 16 October 2017 at 14:14:50 UTC, Ola Fosheim Grøstad 
 wrote:
 On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
 A std::shared_ptr going out of scope can pause the program 
 for just as long as a GC mark-and-sweep.
I don't use shared_ptr much, but why would a single shared_ptr be that slow?
Cascade deletion of nested data structures, with the possibility of causing stack overflow.
Cascaded deletion? That's far more than a shared_ptr… Nobody does that in real code, unless they are prototyping.
Oct 16
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 16 October 2017 at 16:11:05 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 16 October 2017 at 14:24:57 UTC, Paulo Pinto wrote:
 On Monday, 16 October 2017 at 14:14:50 UTC, Ola Fosheim 
 Grøstad wrote:
 On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
 A std::shared_ptr going out of scope can pause the program 
 for just as long as a GC mark-and-sweep.
I don't use shared_ptr much, but why would a single shared_ptr be that slow?
Cascade deletion of nested data structures, with the possibility of causing stack overflow.
Cascaded deletion? That's far more than a shared_ptr… Nobody does that in real code, unless they are prototyping.
You would be amazed what real code on Fortune 500's looks like, specially if it comes from offshored projects.
Oct 16
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 16 October 2017 at 14:14:50 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
 A std::shared_ptr going out of scope can pause the program for 
 just as long as a GC mark-and-sweep.
I don't use shared_ptr much, but why would a single shared_ptr be that slow?
It wouldn't. It's when you have a shared_ptr to an object that has a shared_ptr to an object that has a ... (or unique_ptrs along the way). I saw a paper on this once but my google fun is failing me. Atila
Oct 17
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 17 October 2017 at 10:05:23 UTC, Atila Neves wrote:
 It's when you have a shared_ptr to an object that has a 
 shared_ptr to an object that has a ... (or unique_ptrs along 
 the way).
Well, yes I've seen some online lectures/tutorials that use it for managing graphs and linked lists, but this is overkill in most cases. shared_ptr seems most suited for sharing resources over threads. Although I guess you can get that effect if you use it for tracking cached objects in a database client or something like that. Sounds more like a problem for people developing frameworks than for applications. Frameworks have to make the difficult trade off of whether they should roll their own or use a standard mechanism. End users often would prefer a standard solution I guess.
Oct 17
prev sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
 On Monday, 16 October 2017 at 09:58:46 UTC, Ecstatic Coder 
 wrote:
 On Sunday, 15 October 2017 at 20:42:36 UTC, Laeeth Isharc 
 wrote:
 On Sunday, 15 October 2017 at 07:21:55 UTC, Ecstatic Coder 
 wrote:
 [...]
Out of curiosity, what is it that stops you keeping the heap small and allocating memory manually for the rest?
In D I've the added complexity in trying to use the game engine (cocos2dx, unreal, cryengine) C++ libraries from D. So that's not worth the effort, if I can't use D's powerful standard library as usual. I don't like the idea that any hidden object allocation or string concatenation can trigger a GC for an undefined amount of time. In C++ you also have plenty of objects constructors/destructors called everywhere in your back, but none of them will ever trigger a GC...
A std::shared_ptr going out of scope can pause the program for just as long as a GC mark-and-sweep. Have you tried using a nogc main loop in your programs/games? I'm curious to learn why that might not have worked for you. Atila
Very honestly, shortly after your remark I've tried to use D in connection with cocos2d-x for a small mobile sports game, and after two days I've given up. I've never managed to find an easy way to make D play well with cocos2d-x. Don't ask me about having it run on android. But I'm not disgusted. I still remain VERY interested in being able to developing all my desktop/mobile gaming developements in D. It's just that it seems that I'm not smart enough to make this D/cocos2d-x/android magic happen by myself. And as I said, I'd prefer to be able to regularly ask D to progressively collect its bits of memory in some limited and predefined amount of time (xxx ms) when and where I've decided to, in the Nim way. For that also I'm clearly not smart enough to do the job by myself, and Dmitry has already explained me twice why he's against that... So at the moment I'm just waiting that some D/GC/Android genius manages to make the impossible possible...
Oct 16
prev sibling next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 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 ).
At the moment, for very demanding high-performance web applications, the main choices are : - Dart - Go - C/C++ - Java/Kotlin This is somewhat confirmed by the following benchmark (despite its well known flaws) : https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=query I think that D, with its fiber system and extreme execution speeds, should already have everything needed to compete on the same grounds as Dart and Go. But only if : - the fibers automatically uses all cores if allowed to do so; - the GC problems is designed so that the server never hangs for more than a few milliseconds IN THE WORST CASE (progressive GC) - dedicated HIGH PERFORMANCE web server (cfr Go/Dart) and database access (MySQL, PostgreSQL, Aerospike) libraries are available, preferably as a standard library (like in Dart and Go). And for the third point, I really mean high performance, something that make D's implementation of the (silly) benchmarks immediately go to the top of the chart. If all that is already available, perfect :) Then we just need to add the D version of the benchmarks, and the marketing is done. And moreover I'd be delighted to start using D instead of Go for my next web server developments.
Oct 15
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Sunday, 15 October 2017 at 10:09:02 UTC, Ecstatic Coder wrote:
 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 ).
At the moment, for very demanding high-performance web applications, the main choices are : - Dart - Go - C/C++ - Java/Kotlin This is somewhat confirmed by the following benchmark (despite its well known flaws) : https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=query I think that D, with its fiber system and extreme execution speeds, should already have everything needed to compete on the same grounds as Dart and Go. But only if : - the fibers automatically uses all cores if allowed to do so;
Even if a given fiber is pinned to particular core it will be balanced with typical http request/response model where you have LOTs of short-lived requests. So no changes required.
 - the GC problems is designed so that the server never hangs 
 for more than a few milliseconds IN THE WORST CASE (progressive 
 GC)
Actually prioritizing low latency will hurt RPS you seem to care about. Java can easily stay in top 20 with pauses of up to ~100ms.
 - dedicated HIGH PERFORMANCE web server (cfr Go/Dart) and
Might work. In this benchmark it’s hardly the bottleneck, the hardware used can crank out millions of HTTP responses per second.
 database access (MySQL, PostgreSQL, Aerospike) libraries are 
 available,
That is important actually.
 preferably as a standard library (like in Dart and Go).
Can’t do that. And it’s not standard in Go and Dart but packages, dub should work for that.
 And for the third point, I really mean high performance, 
 something that make D's implementation of the (silly) 
 benchmarks immediately go to the top of the chart.
Well I kind if doing this for Regex at times. Ilia did this with BLAS libraries. If we had a dozen more of performance maniacs with plenty of spare time we’d win every silly benchmark.
 If all that is already available, perfect :)
[snip]
 And moreover I'd be delighted to start using D instead of Go 
 for my next web server developments.
You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.
Oct 15
next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 15 October 2017 at 12:14:02 UTC, Dmitry Olshansky 
wrote:
 On Sunday, 15 October 2017 at 10:09:02 UTC, Ecstatic Coder 
 wrote:
 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 ).
At the moment, for very demanding high-performance web applications, the main choices are : - Dart - Go - C/C++ - Java/Kotlin This is somewhat confirmed by the following benchmark (despite its well known flaws) : https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=query I think that D, with its fiber system and extreme execution speeds, should already have everything needed to compete on the same grounds as Dart and Go. But only if : - the fibers automatically uses all cores if allowed to do so;
Even if a given fiber is pinned to particular core it will be balanced with typical http request/response model where you have LOTs of short-lived requests. So no changes required.
 - the GC problems is designed so that the server never hangs 
 for more than a few milliseconds IN THE WORST CASE 
 (progressive GC)
Actually prioritizing low latency will hurt RPS you seem to care about. Java can easily stay in top 20 with pauses of up to ~100ms.
 - dedicated HIGH PERFORMANCE web server (cfr Go/Dart) and
Might work. In this benchmark it’s hardly the bottleneck, the hardware used can crank out millions of HTTP responses per second.
 database access (MySQL, PostgreSQL, Aerospike) libraries are 
 available,
That is important actually.
 preferably as a standard library (like in Dart and Go).
Can’t do that. And it’s not standard in Go and Dart but packages, dub should work for that.
 And for the third point, I really mean high performance, 
 something that make D's implementation of the (silly) 
 benchmarks immediately go to the top of the chart.
Well I kind if doing this for Regex at times. Ilia did this with BLAS libraries. If we had a dozen more of performance maniacs with plenty of spare time we’d win every silly benchmark.
 If all that is already available, perfect :)
[snip]
 And moreover I'd be delighted to start using D instead of Go 
 for my next web server developments.
You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.
Ok. Still not convinced to use D instead of C++ for my personal use cases (games and other soft real-time apps), but I get the idea. Can you just confirm that D's fibers use most of the available processors/cores by default ? I think this is quite automatic with Elixir's Phoenix framework. http://phoenixframework.org/blog/the-road-to-2-million-websocket-connections (one more silly benchmark btw, they just open the connections without doing anything useful with them) Btw, when I say you can actually develop complete web servers in Dart and Go just with the components provided in the standard libraries, I really mean it, even if I personally also use higher level external libraries/frameworks (from Github), which extend the lower level components of Go's standard library.
Oct 15
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Sunday, 15 October 2017 at 16:29:22 UTC, Ecstatic Coder wrote:
 On Sunday, 15 October 2017 at 12:14:02 UTC, Dmitry Olshansky 
 wrote:
 If all that is already available, perfect :)
[snip]
 And moreover I'd be delighted to start using D instead of Go 
 for my next web server developments.
You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.
Ok. Still not convinced to use D instead of C++ for my personal use cases (games and other soft real-time apps), but I get the idea.
So are the problems you listed not important for the decision or the answers are not convincing?
 Can you just confirm that D's fibers use most of the available 
 processors/cores by default ?
There is no “by default” in any non-managed language. If you are coming from C++ I’m really surprised to see this turn of phrase. Speaking of defaults - Vibe.d is built on Fibers and has muliti-core mode that scales. It may have some issues on huge number of cores but it does work.
 I think this is quite automatic with Elixir's Phoenix framework.
I take it Phoenix framework is “default” in Elixir? :)
 http://phoenixframework.org/blog/the-road-to-2-million-websocket-connections
 (one more silly benchmark btw, they just open the connections 
 without doing anything useful with them)

 Btw, when I say you can actually develop complete web servers 
 in Dart and Go just with the components provided in the 
 standard libraries, I really mean it, even if I personally also
I programmed in Go. I also was part of Dart team for about a year. So yeah, I know what you mean.
 use higher level external libraries/frameworks (from Github), 
 which extend the lower level components of Go's standard 
 library.
You can with C’s standard library. It’s all a matter of perspective and amount of stuff in std vs amount of your code on top. IMHO what I see is that everybody goes on to invent a library that is somehow better than std lib one.
Oct 15
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Btw, when I say you can actually develop complete web servers 
 in Dart and Go just with the components provided in the 
 standard libraries, I really mean it, even if I personally also
I programmed in Go. I also was part of Dart team for about a year. So yeah, I know what you mean.
Ok, then please can you explain why you say about web development libraries that "it’s not standard in Go and Dart", as you are probably the most informed person on that subject from the whole D community. For instance, the web server behind my personal web site is EXCLUSIVELY based on Go's standard library, nothing else was used... And moreover its code is incredibly concise and performant. Great job from Google engineering teams...
Oct 16
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 16 October 2017 at 09:31:51 UTC, Ecstatic Coder wrote:
 Btw, when I say you can actually develop complete web servers 
 in Dart and Go just with the components provided in the 
 standard libraries, I really mean it, even if I personally 
 also
I programmed in Go. I also was part of Dart team for about a year. So yeah, I know what you mean.
Ok, then please can you explain why you say about web development libraries that "it’s not standard in Go and Dart",
Web development for me is usually a fair bit more then: Register a bunch of handler functions that do Http Request -> Http Response ( Go std lib cira 2015) There is templating, routing, some kind of ORM (sick) / ODM / DAO, access-control, authorization, marshaling, these things. I recognize some of these have simple versions in Go’s std lib like templates and json serialization. My point is not that http server is not bundled but rather that for me “whole http server” would imply some backend work i.e. DB drivers and other 3rd party stuff. Go projects I worked on pulled in a great amount of these. Too much I’d say. There is a package for everything in Go or so it seems.
 as you are probably the most informed person on that subject 
 from the whole D community.

 For instance, the web server behind my personal web site is 
 EXCLUSIVELY based on Go's standard library, nothing else was 
 used...
I just double checked and yes, you can’t do SQL without database “driver” package. So I’m really curious how you get by without it... Files/REST API?
 And moreover its code is incredibly concise and performant. 
 Great job from Google engineering teams...
They have very nice runtime since around 1.6. Can’t agree on consie part, Go always looks verbose and repetative, a bit like Java 1.2. Dart also features quite capable JIT and runtime, in contrast to Go it’s quite concise but more high-level.
Oct 16
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Monday, 16 October 2017 at 17:17:29 UTC, Dmitry Olshansky 
wrote:
 On Monday, 16 October 2017 at 09:31:51 UTC, Ecstatic Coder 
 wrote:
 Btw, when I say you can actually develop complete web 
 servers in Dart and Go just with the components provided in 
 the standard libraries, I really mean it, even if I 
 personally also
I programmed in Go. I also was part of Dart team for about a year. So yeah, I know what you mean.
Ok, then please can you explain why you say about web development libraries that "it’s not standard in Go and Dart",
Web development for me is usually a fair bit more then: Register a bunch of handler functions that do Http Request -> Http Response ( Go std lib cira 2015) There is templating, routing, some kind of ORM (sick) / ODM / DAO, access-control, authorization, marshaling, these things. I recognize some of these have simple versions in Go’s std lib like templates and json serialization. My point is not that http server is not bundled but rather that for me “whole http server” would imply some backend work i.e. DB drivers and other 3rd party stuff. Go projects I worked on pulled in a great amount of these. Too much I’d say. There is a package for everything in Go or so it seems.
 as you are probably the most informed person on that subject 
 from the whole D community.

 For instance, the web server behind my personal web site is 
 EXCLUSIVELY based on Go's standard library, nothing else was 
 used...
I just double checked and yes, you can’t do SQL without database “driver” package. So I’m really curious how you get by without it... Files/REST API?
 And moreover its code is incredibly concise and performant. 
 Great job from Google engineering teams...
They have very nice runtime since around 1.6. Can’t agree on consie part, Go always looks verbose and repetative, a bit like Java 1.2. Dart also features quite capable JIT and runtime, in contrast to Go it’s quite concise but more high-level.
If you had tried my website you would have noticed that it's a static web site, so no SQL was harmed during its production ;) And to be 100% honest with you, indeed I actually don't program in Go but in my own proprietary language which emits Go code from a syntax similar to my Phoenix language, hence the "concise" adjective. (it's here if you are curious about it : https://github.com/senselogic/PHOENIX) Additionally to the Phoenix-like syntax, Helix allows me to use Allman style, macro-based genericity (through multi-token substitution), which is nice, even if several Go fanatics have explained me in a not so kind manner how and why it would silly and useless to do that, as Go is already perfect. (I had the same remarks from PHP coders for Phoenix btw). But I don't care, it's my own personal language, and since one of Go's designed has decided to piss over me twice (guess who), I've decided to keep it for me and let the Go community program the way they want, i.e. by using slow-as-hell interfaces for everything or repeatedly copy-paste-modify the same lines of code... And YES, despite their flaws, I still think that Dart and Go are by far the best web development languages we have right now, especially compared to PHP and JavaScript/Node.js.
Oct 16
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 16 October 2017 at 20:02:16 UTC, Ecstatic Coder wrote:
 On Monday, 16 October 2017 at 17:17:29 UTC, Dmitry Olshansky 
 wrote:
 On Monday, 16 October 2017 at 09:31:51 UTC, Ecstatic Coder
If you had tried my website you would have noticed that it's a static web site, so no SQL was harmed during its production ;) And to be 100% honest with you, indeed I actually don't program in Go but in my own proprietary language which emits Go code from a syntax similar to my Phoenix language, hence the "concise" adjective.
I actually think that Go is quite an attractive _runtime_ to target. Sooner or later somebody should notice that too.
 (it's here if you are curious about it : 
 https://github.com/senselogic/PHOENIX)

 Additionally to the Phoenix-like syntax, Helix allows me to use 
 Allman style, macro-based genericity (through multi-token 
 substitution), which is nice, even if several Go fanatics have 
 explained me in a not so kind manner how and why it would silly 
 and useless to do that, as Go is already perfect.
Yeah, the biggest disservice to Go community is a decent amount of blind fanatics.
 (I had the same remarks from PHP coders for Phoenix btw).

 But I don't care, it's my own personal language, and since one 
 of Go's designed has decided to piss over me twice (guess who), 
 I've decided to keep it for me and let the Go community program 
 the way they want, i.e. by using slow-as-hell interfaces for 
 everything or repeatedly copy-paste-modify the same lines of 
 code...
Yeah, seen a lot of these. And then, of course, crude in-house codegen tools :)
 And YES, despite their flaws, I still think that Dart and Go 
 are by far the best web development languages we have right 
 now, especially compared to PHP and JavaScript/Node.js.
Oct 16
prev sibling next sibling parent reply Jerry <hurricane hereiam.com> writes:
On Sunday, 15 October 2017 at 16:29:22 UTC, Ecstatic Coder wrote:
 If all that is already available, perfect :)
[snip]
 And moreover I'd be delighted to start using D instead of Go 
 for my next web server developments.
You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.
Ok. Still not convinced to use D instead of C++ for my personal use cases (games and other soft real-time apps), but I get the idea.
I switched my personal game to D from C++. Was easy, most of it was just copy paste. I was writing a math library to replace the one I was using to make it a bit more light way and to fit my needs a bit more. I didn't like how some thing were implemented in the library I was using. So I started with templates, I need multiple types and what not for the same purpose. At some point I have a function that needs to take 2 different template types. It starts to get so convoluted, order matters cause C++ still just uses copy-paste-includes and I don't think modules made it into C++17. I wrote the same library in half the code, in a way that's more readable and manageable. I didn't have to define things so that they would work, I could define them logically the way I'd expect them to be. Mixins also reduced code quite a bit, generating functions for different types and dimensions. Even though you have constexpr if statements now you still need to define all the function bodies even if they all can go in one function body now.
Oct 15
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Monday, 16 October 2017 at 02:10:31 UTC, Jerry wrote:
 On Sunday, 15 October 2017 at 16:29:22 UTC, Ecstatic Coder 
 wrote:
 If all that is already available, perfect :)
[snip]
 And moreover I'd be delighted to start using D instead of Go 
 for my next web server developments.
You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.
Ok. Still not convinced to use D instead of C++ for my personal use cases (games and other soft real-time apps), but I get the idea.
I switched my personal game to D from C++. Was easy, most of it was just copy paste. I was writing a math library to replace the one I was using to make it a bit more light way and to fit my needs a bit more. I didn't like how some thing were implemented in the library I was using. So I started with templates, I need multiple types and what not for the same purpose. At some point I have a function that needs to take 2 different template types. It starts to get so convoluted, order matters cause C++ still just uses copy-paste-includes and I don't think modules made it into C++17. I wrote the same library in half the code, in a way that's more readable and manageable. I didn't have to define things so that they would work, I could define them logically the way I'd expect them to be. Mixins also reduced code quite a bit, generating functions for different types and dimensions. Even though you have constexpr if statements now you still need to define all the function bodies even if they all can go in one function body now.
Thanks for sharing your experience !
Oct 16
parent SrMordred <patric.dexheimer gmail.com> writes:
 From https://wiki.dlang.org/Vision/2017H2:

2.  nogc: Use of D without a garbage collector, most likely by 
using reference counting and related methods Unique/Weak 
references) for reclamation of resources. This task is made 
challenging by the safety requirement.

Eventually it will come (I hope) :)

I'm on the game programming in D train also.

And its a bless comparing to C++, but I have the same concerns 
about the impredictable GC pause time.
Oct 16
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-10-15 18:29, Ecstatic Coder wrote:

 Can you just confirm that D's fibers use most of the available 
 processors/cores by default ?
It depends entirely what you do with with the fibers. When it comes to vibe.d, it will only run on one core by default, last time I checked. Actually, I looked up the option for enabling multithreading for handling HTTP requests, it's now deprecated [1] and the recommendation is instead: "If possible, instead of threads, the use of separate processes is more robust and often faster" [1] http://vibed.org/api/vibe.http.server/HTTPServerOption.distribute -- /Jacob Carlborg
Oct 16
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Monday, 16 October 2017 at 09:30:03 UTC, Jacob Carlborg wrote:
 On 2017-10-15 18:29, Ecstatic Coder wrote:

 Can you just confirm that D's fibers use most of the available 
 processors/cores by default ?
It depends entirely what you do with with the fibers. When it comes to vibe.d, it will only run on one core by default, last time I checked. Actually, I looked up the option for enabling multithreading for handling HTTP requests, it's now deprecated [1] and the recommendation is instead: "If possible, instead of threads, the use of separate processes is more robust and often faster" [1] http://vibed.org/api/vibe.http.server/HTTPServerOption.distribute
Nowadays most web servers are multicore, so that's probably not very good to optimize their raw performance.
Oct 16
prev sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
 database access (MySQL, PostgreSQL, Aerospike) libraries are available,
That is important actually.
So important that it should be a Priority 0 Must Have.
 preferably as a standard library (like in Dart and Go).
Can’t do that. And it’s not standard in Go and Dart but packages, dub should work for that.
I've been thinking about this question a LOT, and I'm not convinced it's impossible to put the DB libs into the standard library... -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Oct 15
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Sunday, 15 October 2017 at 20:24:02 UTC, Adam Wilson wrote:
 database access (MySQL, PostgreSQL, Aerospike) libraries are 
 available,
That is important actually.
So important that it should be a Priority 0 Must Have.
Luckily it should also be quite strightforward to write them. At minimum there would be a C, Go, Java and Python “driver” to look at. Also surprisingly, D has superior driver for MySQL that talks native binary protocol while most other languages use the text mode.
 preferably as a standard library (like in Dart and Go).
Can’t do that. And it’s not standard in Go and Dart but packages, dub should work for that.
I've been thinking about this question a LOT, and I'm not convinced it's impossible to put the DB libs into the standard
Problem is - the development of std has glacial pace. Even if you put say Aerospike in std, I don’t think it’s in our best interest to have stagnated DB libs. DBs add features and ship new versions all the time. What might work is JDBC style approach - having a common interface in std with implementations in 3rd party. SQL might work this way. NoSQL though is highly irregular and benefits primarily from features unique to a particular vendor.
Oct 15
next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/15/17 22:20, Dmitry Olshansky wrote:
 On Sunday, 15 October 2017 at 20:24:02 UTC, Adam Wilson wrote:
 database access (MySQL, PostgreSQL, Aerospike) libraries are available,
That is important actually.
So important that it should be a Priority 0 Must Have.
Luckily it should also be quite strightforward to write them. At minimum there would be a C, Go, Java and Python “driver” to look at. Also surprisingly, D has superior driver for MySQL that talks native binary protocol while most other languages use the text mode.
The most important SQL DB's all have high quality C libraries. Why not leverage those? I don't understand the obsession with having everything written in native D. To be bluntly honest, I find the VisualD suffers greatly from not being written as a C# MEF component (Visual Studio's plugin system). There is no demonstrable advantage to writing an IDE plugin in D (as opposed to using the native language of the IDE) other than proving that it can be done. Also, I would caution that MSFT is working *very* hard to retire the COM based plugin system for Visual Studio (here is the direction they are heading: https://github.com/dotnet/project-system). Honestly we could probably knock together an integrated D plugin based on Common Project System fairly quickly, but we'd have to do it in C#. Technically you could write a P/Invoke wrapper out to D, but ... why?
 preferably as a standard library (like in Dart and Go).
Can’t do that. And it’s not standard in Go and Dart but packages, dub should work for that.
I've been thinking about this question a LOT, and I'm not convinced it's impossible to put the DB libs into the standard
Problem is - the development of std has glacial pace. Even if you put say Aerospike in std, I don’t think it’s in our best interest to have stagnated DB libs. DBs add features and ship new versions all the time. What might work is JDBC style approach - having a common interface in std with implementations in 3rd party. SQL might work this way.
I've been (slowly) working on exactly this. I started with a concept loosely based on ADO.NET but lately it's more D idiomatic than that. Also, because SQL is what it is (a text based query language) it would actually be possible to include reference implementations of the major DB vendors for the common interface. (MySQL, PgSQL, etc.)
 NoSQL though is highly irregular and benefits primarily from features
 unique to a particular vendor.
Completely agree. However, some types of NoSQL DB's could be hidden behind generic interfaces, for example key-value stores. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Oct 16
parent Jacob Carlborg <doob me.com> writes:
On 2017-10-16 09:45, Adam Wilson wrote:

 The most important SQL DB's all have high quality C libraries. Why not 
 leverage those? 
If the drivers should be compatible with vibe.d the underlying C library needs to be compatible vibe.d's asynchronous event model. I don't know if they all (the C libraries) support asynchronous communication. -- /Jacob Carlborg
Oct 16
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-10-16 07:20, Dmitry Olshansky wrote:
 On Sunday, 15 October 2017 at 20:24:02 UTC, Adam Wilson wrote:
 database access (MySQL, PostgreSQL, Aerospike) libraries are available,
That is important actually.
So important that it should be a Priority 0 Must Have.
Luckily it should also be quite strightforward to write them. At minimum there would be a C, Go, Java and Python “driver” to look at.
There are already drivers for MySQL (mysql-native) and PostgreSQL (ddb). -- /Jacob Carlborg
Oct 16
prev sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Monday, 16 October 2017 at 05:20:16 UTC, Dmitry Olshansky 
wrote:
 On Sunday, 15 October 2017 at 20:24:02 UTC, Adam Wilson wrote:
 database access (MySQL, PostgreSQL, Aerospike) libraries are 
 available,
That is important actually.
So important that it should be a Priority 0 Must Have.
Luckily it should also be quite strightforward to write them. At minimum there would be a C, Go, Java and Python “driver” to look at. Also surprisingly, D has superior driver for MySQL that talks native binary protocol while most other languages use the text mode.
 preferably as a standard library (like in Dart and Go).
Can’t do that. And it’s not standard in Go and Dart but packages, dub should work for that.
I've been thinking about this question a LOT, and I'm not convinced it's impossible to put the DB libs into the standard
Problem is - the development of std has glacial pace. Even if you put say Aerospike in std, I don’t think it’s in our best interest to have stagnated DB libs. DBs add features and ship new versions all the time. What might work is JDBC style approach - having a common interface in std with implementations in 3rd party. SQL might work this way. NoSQL though is highly irregular and benefits primarily from features unique to a particular vendor.
This is the best answer I've even been given on the main drawback of a standard library component. Then I suggest that some script is used which "standardizes" the module component of a thirdparty library to make it belong to the "std" namespace, and put the result in the DMD/GDC/LDC installation packages. Best of both worlds...
Oct 16
prev sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
techempower bench is not good. It is wierd. On my pc vibe.d is much faster
with techempower benchmark. So I do not beleive their results

Dne 15. 10. 2017 12:10 odpoledne napsal u=C5=BEivatel "Ecstatic Coder via
Digitalmars-d" <digitalmars-d puremagic.com>:

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 advantag=
es
 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 ).
At the moment, for very demanding high-performance web applications, the main choices are : - Dart - Go - C/C++ - Java/Kotlin This is somewhat confirmed by the following benchmark (despite its well known flaws) : https://www.techempower.com/benchmarks/#section=3Ddata-r14&hw=3Dph&test=3Dq= uery I think that D, with its fiber system and extreme execution speeds, should already have everything needed to compete on the same grounds as Dart and Go. But only if : - the fibers automatically uses all cores if allowed to do so; - the GC problems is designed so that the server never hangs for more than a few milliseconds IN THE WORST CASE (progressive GC) - dedicated HIGH PERFORMANCE web server (cfr Go/Dart) and database access (MySQL, PostgreSQL, Aerospike) libraries are available, preferably as a standard library (like in Dart and Go). And for the third point, I really mean high performance, something that make D's implementation of the (silly) benchmarks immediately go to the top of the chart. If all that is already available, perfect :) Then we just need to add the D version of the benchmarks, and the marketing is done. And moreover I'd be delighted to start using D instead of Go for my next web server developments.
Oct 15
prev sibling parent Tony <tonytdominguez aol.com> writes:
On Friday, 6 October 2017 at 21:12:58 UTC, Rion wrote:

 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 ).
How can GC issues be a myth if the Go developers did an impressive massive amount of work trying to reduced GC pauses?
Oct 15
prev sibling next 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 parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
 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
To really compete with C++ on the same grounds, D needs a no-GC standard library, which would behave as close as possible as the GC-based standard library. Reference-counting is used a lot in C++ game development, for resource management. In C++, using just strong and weak pointer classes for arrays, strings and slices, you can develop programs which look like garbage collected code.
Oct 14
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 next sibling parent reply 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
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Saturday, 7 October 2017 at 09:37:12 UTC, Radu wrote:
 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 guess a non-GC solution for throw new Exception will help with quite a lot. What to do about the rest (at least for Phobos)?
 - 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).
Would it make sense to have a BetterC version define for Phobos? Or is this a terrible idea? So you could still use some subset of Phobos from BetterC mode, and maybe this subset could be expanded over time? And maybe people would write a complimentary set of functions to cover the missing most useful things in a way that doesn't depend on the runtime? It makes sense what you say about allocators - it would be nice to be able to write BetterC code using those. I used dscanner quickly to see what the imports are, and I wonder how much work it would be to do what you propose. core.atomic core.bitop core.exception core.internal.spinlock core.memory core.stdc.errno core.stdc.stdlib core.stdc.string core.sys.posix.pthread core.sys.posix.sys.mman core.sys.windows.unknwn core.sys.windows.windows core.thread std.algorithm.comparison std.algorithm.iteration std.algorithm.mutation std.algorithm.searching std.algorithm.sorting std.array std.c.stdlib std.c.string std.concurrency std.conv std.exceptionstd.file std.format std.internal.test.dummyrange std.math std.meta std.random std.range std.range.primitives std.stdio std.traits std.typecons
Oct 07
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc wrote:
 Would it make sense to have a BetterC version define for Phobos?
Quite a lot of Phobos already works that way.
Oct 07
next sibling parent SrMordred <patric.dexheimer gmail.com> writes:
I think the GC discussion think will never go away because of the 
amount of c++ coders that come here.

If you want to flee from C++ you have two realistic options: Rust 
and D.

When you are looking at D and comparing metaprogramming, traits, 
ranges, UFCS, etc, its amazing: 'SO MUCH better than C++, i'ĺl 
leave right now!'

BUT then there is GC. And its not only about performance. You are 
programming at 5 10, 15 years with manual memory management, you 
lived the your entire live under the law of "you will not pay for 
what you don't use". Then you have to accept that you have a GC 
doing things under the hood. Even if you understand whats going 
on (and thanks the GC series for that :)), its a difficult 
paradigm shift.

I never had problems with GC, and im fine programming with it, 
but there is a c++ ghost in my ear every time speaking about 
manual management ;P

But im so used to D now that everytime I look back at c++ it give 
me chills. and BetterC and noGC libs are coming, so I think there 
is a ever brighter future ahead :)
Oct 07
prev sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Saturday, 7 October 2017 at 20:44:44 UTC, Adam D. Ruppe wrote:
 On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc 
 wrote:
 Would it make sense to have a BetterC version define for 
 Phobos?
Quite a lot of Phobos already works that way.
blog post to enlighten the masses?
Oct 07
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/7/2017 1:36 PM, Laeeth Isharc wrote:
 Would it make sense to have a BetterC version define for Phobos? Or is this a 
 terrible idea?  So you could still use some subset of Phobos from BetterC
mode, 
 and maybe this subset could be expanded over time?  And maybe people would
write 
 a complimentary set of functions to cover the missing most useful things in a 
 way that doesn't depend on the runtime?
It does make sense in general for library functions to be less dependent on linking to the rest of the library. For example, I discovered recently that core.stdc.stdio and core.stdc.errno relied on linking in druntime, making them unusable for BetterC. Fortunately, I found a way to remove those dependencies without any compromises. Of course, this won't always be possible, but it is worth thinking about when designing Phobos code. (One way to do this is to use more templates, as the templates will get instantiated into the user program rather than needing to be linked in from Phobos.)
Oct 07
prev sibling parent Radu <void null.pt> writes:
On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc wrote:
 On Saturday, 7 October 2017 at 09:37:12 UTC, Radu wrote:
 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 guess a non-GC solution for throw new Exception will help with quite a lot. What to do about the rest (at least for Phobos)?
Yes, exceptions are one, but there are strings (arrays in general) for which ref counted needs to work, and it should work in safe mode, so you need scope working to get it...
 - 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).
Would it make sense to have a BetterC version define for Phobos? Or is this a terrible idea? So you could still use some subset of Phobos from BetterC mode, and maybe this subset could be expanded over time? And maybe people would write a complimentary set of functions to cover the missing most useful things in a way that doesn't depend on the runtime?
It would make sense to have a documentation marker that allows one to quickly see that a module/function is usable in betterC mode. Algorithms and the like are first in line but it should be gradually extended to all parts of phobos... Right now this is a guess work.
 It makes sense what you say about allocators - it would be nice 
 to be able to write BetterC code using those.  I used dscanner 
 quickly to see what the imports are, and I wonder how much work 
 it would be to do what you propose.
Yeah - they are entangled with a lot of parts from druntime and phobos, that's why I think they need a redesign that can deliver a core part that works with the C runtime (betterC), then extend on that to have the druntime one.
 core.atomic
 core.bitop
 core.exception
 core.internal.spinlock
 core.memory
 core.stdc.errno
 core.stdc.stdlib
 core.stdc.string
 core.sys.posix.pthread
 core.sys.posix.sys.mman
 core.sys.windows.unknwn
 core.sys.windows.windows
 core.thread
 std.algorithm.comparison
 std.algorithm.iteration
 std.algorithm.mutation
 std.algorithm.searching
 std.algorithm.sorting
 std.array
 std.c.stdlib
 std.c.string
 std.concurrency
 std.conv
 std.exceptionstd.file
 std.format
 std.internal.test.dummyrange
 std.math
 std.meta
 std.random
 std.range
 std.range.primitives
 std.stdio
 std.traits
 std.typecons
Oct 08
prev sibling parent 12345swordy <alexanderheistermann 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...
There is nothing wrong with having a GC however the issues are (IMO): 1.The current implementation of the GC. 2.Doing manual memory with classes in nogc context is impossible (Destroy isn't nogc as it called the finalizer function directly!) 3.Lots of things needed to work before -betterc is useful in c++ heavy projects. The paranoia stems from java terrible GC implementation, it has gotten better over the years, but the damage has been already done in terms of reputation.
Oct 17