On Sun, 2016-06-05 at 19:20 -0700, Walter Bright via Digitalmars-d wrote:
> […]
> 
> * The garbage collector eliminates probably 60% of potential users right off.

And i bet over 80% of them are just saying this based on zero evidence, just prejudice.

Go went with the attitude "Go has a GC, if you cannot deal with that #### off". Many people did exactly that and the Go community said "byeeee". Arrogant this may have been, but Pike, Cox, et al. stuck to their guns and forged a community and a niche for the language. This then created traction. Now GC in Go is not an issue.

D has a different problem in that it is not a new language, it cannot ride a "new language" hype wave to get over knee-jerk opinions.

D needs t make it clear there is the normal GC approach proven to work fine over the years, just look at Go, and there is the GC-less mode for those that really do need absolute control over all memory management. If D does not have this then C++ and Rust win.

If GC-less D is a problem then why not let people who want absolute control of memory at all times go to another language, e.g. C, C++, Rust. They will anyway.

So maybe get rid of CG-less mode as Go has done and not try to make D a language for people who are already prejudiced against GC and for C, C++ and Rust?

Ig GC is a problem for these people, let them go.

> * Tooling is immature and of poorer quality compared to the competition.

This is true.

We have too many half-finished attempt at things, basically because everything is volunteer, not directly associated with work, activity. Nothing wrong with this per se, but an obvious explanation why it is so. Unless an oirganization or seven put some work-oriented effort into the tooling, nothinkg will change.

I would suggest three ways forward:

1. Get effort on the IntelliJ IDEA and CLion plugin. Kingsley has made a start. I suggest using his work as a basis and doing a new version written in Kotlin instead of Java. Kotlin will be easier than Java for D people to work with and easy for Java people to work with.

2. Get effort on the DDT Eclipse plugin. Bruno has declared it finished, which is fine, but I would say it should not be treated that way.

3. Have one lightweight D realized cross platform IDE. Qt us probably the best widget set to use for this. My model here is LiteIDE which is a Qt-based Go IDE realized in C++. It should of course be realized in Go, but there are no Qt bindings for Go, only QML ones.

> * Safety has holes and bugs.

Then so does C, C++ and Rust, so this is just a comment made because it can be made and sounds bad. Bad enough to salve the conscience of the speaker as to why they are not already using D.

What does safety mean here anyway. C++ safety perhaps?

> * Hiring people who know D is a problem.

Definitely.

But this is also an excuse since there were no Go programmers, no Rust programmers, no C++ programmers, yet now there is no problem. The point here is that a few organizations just need to take a public stance on using the language to create a buzz and traction either happens (as with Go) or it doesn't.

> * Documentation and tutorials are weak.

True. This is a resourcing issue. Go had full resourcing from Google, and then later others, to get to the state they have – which is not half bad.

> * There's no web services framework (by this time many folks know of
> D, but of
> those a shockingly small fraction has even heard of vibe.d). I have
> strongly
> argued with Sönke to bundle vibe.d with dmd over one year ago, and
> also in this
> forum. There wasn't enough interest.

vibe.d is not a full Web services/applications framework in most people's eyes, it is just the event loop. I guess it is like saying Node is a framework without recognizing the importance of npm and the library of REST, SQL, and other components. Another analogy would be saying Flask is a web framework without pip, SQLAlchemy, etc.

> * (On Windows) if it doesn't have a compelling Visual Studio plugin,
> it doesn't
> exist.

I guess Windows people are so wedded to Visual Studio this is true.

> * Let's wait for the "herd effect" (corporate support) to start.

Seems reasonable to me. Why should organization X take a risk if organization Y hasn't already. This is the position of businesses doomed to failure. Without some risk taking there is no new business and hence no growth, not even status quo.

So target this decade old technology at less risk averse organizations. Likely this means SMEs, probably small businesses (or small business units within bigger businesses) simply because they are generally less risk averse.

> * Not enough advantages over the competition to make up for the weaknesses above.

A position clearly based in a total lack of knowledge, probably of the technology they are currently using. This attitude is simply the risk averse position in another guise.

It is worth taking note of these and learning from them, clearly. But perhaps D as a language and community should be less defensive about the language and its position in the world. Let's stop the "it's a better C++" line, that is clearly a dead route to traction. Let's take lessons from Go, Rust, Kotlin. Find the things that D does well, in the organizations that use it and push those.

Go came along as a systems programming language for Google interns to do productive work and not get things wrong. It has ended up as a premier Web programming language and other things taking market share from PHP and Python as well as C. Yes it had the "better C" angle but it did not agamize about how to move people from C. Yes it had Google and hype, but it gained traction both because of that and in spite of that.

Rust is pushing the "Rust is a better C++ but with memory safety" the fact that it is a quasi-functional language isn't being made enough of. Many people are blocked from using current C libraries because of many features of Rust. So for example trying to use GStreamer from Rust is noted as being fundamentally impossible by the core GStreamer team, and they have been trying – to the extent of having to contemplate a new implementation in Rust. D has a big win here as it already has a fully working GStreamer adapter API – though I wish it were not a part of GtkD but a separate thing.

So where should D go? Let's cease the defensive attitude of trying to compete with C++ where C++ is entrenched. Let us take D out to people as a native code language with a declarative feel that has excellent data structures and algorithms, concurrency, parallelism; a language good for computation. Many in finance are already using it. Market their usage, leave the defensive approach and promote the organizations who have taken the risk so other organizations can see what they have done.

-- 
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 Monday, 6 June 2016 at 07:44:22 UTC, Mike Parker wrote:
> Where does this impression come from that Windows is a second-class citizen?

64-bit support seemed to take forever to reach Windows.

On Mon, 2016-06-06 at 05:28 +0000, ketmar via Digitalmars-d wrote:
> On Monday, 6 June 2016 at 05:13:11 UTC, Daniel Kozak wrote:
> > You can still unregister your critical thread from GC.
> 
> exactly. that's what i did in my sound engine, and it works like a charm: i can enjoy hiccup-less ogg replaying on the background while the main code enjoys GC.

This should be marketed as a major feature of D: the language with a GC for those situations where you want it, and manual memory management for thse cases where you do not want a GC.

What is there not to like here? Why are we still debating the GC at all, it is a done deal. OK so maybe new GC algorithms could be tried. Go did this, why not D.

-- 
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 6/6/2016 1:04 AM, Observer wrote:
> On Monday, 6 June 2016 at 07:01:33 UTC, Walter Bright wrote:
>> On 6/5/2016 11:38 PM, rikki cattermole wrote:
>>> On 06/06/2016 6:29 PM, Andrei Alexandrescu wrote:
>>>> On 6/6/16 6:17 AM, Andre Pany wrote:
>>>>> to be usable for companies which want to create economic software,
>>>>> in my opinion D lacks std.decimal.
>>>>
>>>> Do C, C++, Java, Go, or Rust have a standard decimal type? -- Andrei
>>
>> Apparently there's a spec: http://speleotrove.com/decimal/decarith.html
>
> There's been a lot of work on decimal floating-point types for
> C and C++, even if they haven't yet made it into the languages.
> See, for instance:
>
> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1312.pdf
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.html

Interestingly, that contains links to open source C implementations, meaning we can just provide a D wrapper.

https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library/

http://speleotrove.com/decimal/decnumber.html

> and
> http://www.quadibloc.com/comp/cp020302.htm
> the last of which is not a standards-related document but
> provides some interesting detail.
>
> The point being, while decimal floats are something to be
> wished for, it's a complex matter, not something that can be
> quickly thrown together.
>
> That said, GNU C++ does provide some support:
> https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html

On Monday, 6 June 2016 at 08:15:42 UTC, Russel Winder wrote:
> 3. Have one lightweight D realized cross platform IDE.
by the way, Buggins has dlangIDE written with his dlangUI package. it is cross-platform, has debugger support, and written in D!

On Mon, 2016-06-06 at 06:24 +0000, Mithun Hunsur via Digitalmars-d wrote:
> […]

> The problem is that D is targeted as a multi-paradigm systems programming language, and while it's largely successful at that, the GC doesn't fit in with that domain by nature of its existence.
> 
> There's no problem with _having_ a GC, it just shouldn't be the default case for what's meant to be a systems language, especially when language and standard library features become dependent upon it.

No. As evidence I give you Go. The whole "it's a systems programming language so it cannot have GC" is just so wrong in 2016 (as it was in 2004). Having a GC for a time critical real-time streaming application is probably a bad idea, so turn GC off for that. D can do that.

D having a GC is not the problem, the problem is the D community agamizing about a wrong issue instead of focusing on the real one: when to switch the GC off.

> But I digress: we've had this debate before, we're having it now, and we'll keep having it well into the future :-)

If the D community does continue to debate this, then D really will die as a language. This is a dead issue. It has gone to the debating hall in the sky. It is an ex-issue.

-- 
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 Monday, 6 June 2016 at 08:18:20 UTC, Russel Winder wrote:
> On Mon, 2016-06-06 at 05:28 +0000, ketmar via Digitalmars-d wrote:
>> On Monday, 6 June 2016 at 05:13:11 UTC, Daniel Kozak wrote:
>> > You can still unregister your critical thread from GC.
>> 
>> exactly. that's what i did in my sound engine, and it works like a charm: i can enjoy hiccup-less ogg replaying on the background while the main code enjoys GC.
>
> This should be marketed as a major feature of D: the language with a GC for those situations where you want it, and manual memory management for thse cases where you do not want a GC.

it is even better: i do *zero* manual memory management in Follin! synthesizers are simple classes, and they are automatically anchored with __gshared variables (when user is creating a new replay channel). so i actually enjoying the best things from both worlds! ;-)

On Mon, 2016-06-06 at 08:29 +0200, Andrei Alexandrescu via Digitalmars- d wrote:
> On 6/6/16 6:17 AM, Andre Pany wrote:
> > to be usable for companies which want to create economic software, in my opinion D lacks std.decimal.
> 
> Do C, C++, Java, Go, or Rust have a standard decimal type? -- Andrei

No, but then why is this a factor?

Java has a BigDecimal but it isn't quite what you think it might be.

Many (financial) organizations create their own.  They tend to treat them as asset rather than infrastructure. I know of two C++ ones in this category.

If having a decimal feature in the standard library, or at least easily available as a third-party library, would aide D traction, then maybe it should go on the "let's get this done now" agenda?

-- 
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 Mon, 2016-06-06 at 00:01 -0700, Walter Bright via Digitalmars-d wrote:
> On 6/5/2016 11:38 PM, rikki cattermole wrote:
> > On 06/06/2016 6:29 PM, Andrei Alexandrescu wrote:
> > > On 6/6/16 6:17 AM, Andre Pany wrote:
> > > > to be usable for companies which want to create economic
> > > > software,
> > > > in my opinion D lacks std.decimal.
> > > 
> > > Do C, C++, Java, Go, or Rust have a standard decimal type? -- Andrei
> 
> Apparently there's a spec: http://speleotrove.com/decimal/decarith.ht ml

IBM have had hardware decimal numbers for about 50 years.

-- 
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 Mon, 2016-06-06 at 08:24 +0000, ketmar via Digitalmars-d wrote:
> 
[…]
> it is even better: i do *zero* manual memory management in Follin! synthesizers are simple classes, and they are automatically anchored with __gshared variables (when user is creating a new replay channel). so i actually enjoying the best things from both worlds! ;-)

Let the D community drop the angst, we now have two exemplars of GC and no-GC, let's go with instances of software and not worry about abstract problems.

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