On Tuesday, 7 March 2017 at 18:45:55 UTC, Rico Decho wrote:
>> D seems to be in a situation where those who don't care have a crap GC which needs to be improved and those who do care have the tools to deal with it. So there needs to be ongoing replacement of the D GC until there is something good, this is a technical problem. That people who care about the effect of GC still think D is a crap GC-based language implies there is a marketing problem, not a technical one.
>
> But I don't think that D's GC is fine for people who care about it.

You'd have to be a lot more specific on what exactly you care about, since GC always deals with tradeoffs.

>
> If it is, why are people on this forum giving advices on how to disable and/or avoid it for soft real-time applications where a GC freeze can't be tolerated.

Because there are applications where the tradeoffs chosen for D's GC can't be tolerated.

>
> D's GC isn't a crap at all, but better designs and implementations exist, and Nim's GC is one of them.

Better implementations of the same design, probably, but I haven't checked. As far as I've been able to discern on a quick look, Nim's current GC is also a mark-and-sweep GC, with the same tradeoffs as D's GC, i.e. if you can't accept D's GC in an application, you cannot accept Nim's.
Better designs? That, again, depends on what tradeoffs you're willing to make.
For the goal "we want throughput on-par with C" I'm not aware of better designs.

>
> We can either learn from it, or ignore it... But the second solution won't make D more appropriate for soft real-time scenarios...

You'll have to be very explicit in what you think we should learn.
And D is perfectly viable for real-time scenarios: Don't call the GC.

On Tuesday, 28 February 2017 at 23:29:24 UTC, Jared Jeffries wrote:
> I've read the answer to questions like "Which is the best programming language to learn in 2017?".
>
> Nobody was telling anything about D, which is really sad, because in my opinion D could be one of the best answers to this question.
>
> I've answered this question. Better late than never.
>
> I suggest that other "happy users" of this language do the same...

I've written some stuff there.  Something I wrote on Python, that was in a way an indirect suggestion to explore alternatives (and I mentioned D), got 250k views and was sent to a few million people (whether they read it, who knows!).  Of course it's not the number of people that matters, but a few key people.  Weka use D after hearing about it from a tweet from someone they respected - and their use of D makes a big difference for others that follow (there are others too, but they heard about D from other routes).  One or two people at least explored D after reading my post.

It's a good idea to get involved though, provided one doesn't become an irritating language evangelist lacking in balance or perspective.  D is good for some things and people in some situations, but not for everyone.  It's enough that some people who are receptive actually make the commitment to explore it - over time, that will make quite a difference.  That's true, I think, both for the outside world, and inside an organisation.

On Tuesday, 7 March 2017 at 16:26:20 UTC, Russel Winder wrote:
>
> Learn the lesson from Java. It started with a truly crap GC and everyone said Java is crap because the GC is garbage. D has seemingly actually progressed beyond this stage technically but not marketing wise. The Java folk worked on the GC and kept replacing it over and over again. The GC got better and better. Now with the G1 GC almost all the problem have gone away – as has most of the moaning about Java having a crap GC. Most people never notice the GC and those that do, engineer it rather than moaning. The Java GC situation is now a sophisticated one where those who don't really care do not have a problem and those that do care have the tools to deal with it.
>
> D seems to be in a situation where those who don't care have a crap GC which needs to be improved and those who do care have the tools to deal with it.

> So there needs to be ongoing replacement of the D GC until there is something good, this is a technical problem.

Obviously D generates less garbage...

It's really a problem of social organisation as well - as you say in the rest of your post.  For example Sociomantic released their parallel GC, but it's only a solution for linux and not Windows because no fork on Windows.  Why isn't it available in a form that will work with latest dmd master?  Because we haven't collectively been able to organise someone to do the work, and nobody has stepped up to do it voluntarily.  (And similarly with other GC alternatives - I know that memory barriers have problems too).

But it's probably a matter of time only, because resources are beginning to flow into supporting the language.  The D Foundation didn't exist a couple of years ago - and things didn't magically change once it came into existence.  It takes time and the repeated application of effort, but over time it's likely to bear fruit in different ways.

Things develop at their own pace, and more complex things develop more slowly.


> That people who care about the effect of GC still think D is a crap GC-based language implies there is a marketing problem, not a technical one.

Yes, but that's okay too.  Maybe it's a pity if you would like to work in D, and the smaller size of community means more limited opportunities.  But there are jobs in D, and they are growing.  In the meantime, for those who are able to judge things by how they are and not depend on social proof, it might be a source of strategic advantage to adopt the language earlier - and pay the inevitable toll for that, because it is true that the tooling isn't yet completely mature.  Eg some things we worked on:
https://github.com/dlang/dub/pulls/John-Colvin

> We all know that many, many people see the word garbage collector and run a mile in an uneducated prejudiced way. Who cares about them. We care about the people who are willing to try stuff out and have a problem.

Yes - exactly.  Though we can't wave a wand and make problems disappear unless someone is willing to work on them or sponsor development.

One thing that's lacking is a central list of projects that would benefit the language and community that enterprise users might sponsor.  There's the bug bounty program, but that's something a bit different.



Laeeth.

On Monday, 6 March 2017 at 14:49:42 UTC, Atila Neves wrote:
> On Monday, 6 March 2017 at 05:50:01 UTC, Rico Decho wrote:
>>> It's actually rather rare to *need* to avoid the GC -- only niche applications need that, like if you're writing a game engine that has to avoid stop-the-world pauses (which can be easily worked around, btw), or real-time medical applications where if it stops for 10ms somebody dies. 90% of real world programs out there work just fine with the GC.
>>
>> Actually it's my case. I'd LOVE to use D for game development for instance, but I won't take the risk of having the GC pause the game when I don't want to, even for just an unknown amount of milliseconds, and even if I know that anyway I'll try to limit dynamic allocations by using caches etc.
>
> If this isn't a perfect example of D's marketing problem I don't know what is. Someone who likes D and takes the time to write on the forum yet thinks the GC will randomly run no matter what.
>
> To make it abundantly clear: I'm not bashing on you in the slightest, Rico Decho. I'm just pointing out that there's a clear problem here in that we can't expect to convert e.g. C++ game developers who have never written a line of D before if we haven't even managed to educate the community yet.


"Unfortunately, I have no ideas on how to remedy the situation. "

A start would be to link this page prominently from near the front page:
https://p0nce.github.io/d-idioms/#The-impossible-real-time-thread
https://dlang.org/articles.html

On Saturday, 4 March 2017 at 19:36:30 UTC, Jon Degenhardt wrote:
> On Saturday, 4 March 2017 at 09:13:15 UTC, Seb wrote:
>> On Friday, 3 March 2017 at 19:18:31 UTC, jmh530 wrote:
>>> A Jupyter kernel would go a long way to students being able to easily play around with it in a browser. There's already dabble (D REPL) that one could make use of. I was surprised at the breadth of the list of kernels available these days.
>>
>> There is also drepl:
>>
>> https://github.com/drepl/drepl
>>
>> though of course it's not comparable with a Jupyter kernel.
>
> A D repl followed by a Jupyter kernel would be a great assist in engaging the data science community.

A Jupyter kernel exists - written by John Colvin.  It works and I have used it, and you can write python in one sell and D in another.  It needs some work though, and so I am sure if somebody would like to contribute pull requests John would be happy to consider them.

https://github.com/John-Colvin/PydMagic

Well - I am not sure if it's officially a kernel as I can't remember how PydMagic works.  But in effect it gets you most of the way there and is usable.

On Wednesday, 15 March 2017 at 21:10:49 UTC, Laeeth Isharc wrote:
>
> A Jupyter kernel exists - written by John Colvin.  It works and I have used it, and you can write python in one sell and D in another.  It needs some work though, and so I am sure if somebody would like to contribute pull requests John would be happy to consider them.
>
> https://github.com/John-Colvin/PydMagic
>
> Well - I am not sure if it's officially a kernel as I can't remember how PydMagic works.  But in effect it gets you most of the way there and is usable.

I thought PydMagic allows one to call easily write D code to call in some Python code in Jupyter. A D Jupyter kernel would allow one to use Jupyter with D the same as one could use Python or R. PydMagic probably gets part of the way there, and some other projects mentioned above probably would help in other ways.

I consider it a nice-to-have, but I wouldn't give it a super high priority. The real advantage is for getting people who would otherwise use Python or R or other languages to use D. rdmd works just fine for me.

On Wed, 2017-03-15 at 23:36 +0000, jmh530 via Digitalmars-d wrote:
> […]
> otherwise use Python or R or other languages to use D. rdmd works
> just fine for me.

Except that rdmd needs separating out as a distinct thing so that ldc
users can use it.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 03/16/2017 05:48 AM, Russel Winder via Digitalmars-d wrote:
>
> Except that rdmd needs separating out as a distinct thing so that ldc
> users can use it.
>

I'm pretty sure it does work fine with ldc. Just do:

rdmd --compiler=ldmd [...otherflags...]

On Thu, 2017-03-16 at 19:54 -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> On 03/16/2017 05:48 AM, Russel Winder via Digitalmars-d wrote:
> > 
> > Except that rdmd needs separating out as a distinct thing so that
> > ldc
> > users can use it.
> > 
> 
> I'm pretty sure it does work fine with ldc. Just do:
> 
> rdmd --compiler=ldmd [...otherflags...]

The problem is that it is only bundled with dmd as far as I can tell.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder