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


-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
Oct 06 2017
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 



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



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



 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

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

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

 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. 

C/C++ we cannot easily inter-operate with them.

I like D because I get a language that feels comfortably similar to 

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

 inter-operate with them.



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


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)




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

 either, and unlike C/C++ we cannot easily inter-operate with them.



 be receptive to D?  Plenty of people have approached D from Java:



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 

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


 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)


 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 

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




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

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 

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