On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:
> I didn't quite understand that sentence. What is the problem with the current design that prevents D from gaining momentum?

And of course memory management, which is constantly brought up by ex-D users:

https://www.osnews.com/story/132286/rust-1-46-0-released/#comments

Probably the issue with most impact on adoption.

On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:
> I didn't quite understand that sentence. What is the problem with the current design that prevents D from gaining momentum?

D does have momentum.

Some obstacles as I see them are:
  * no corporate/government/academic sponsor backing the language
  * garbage collection

How one courts a sponsor, I do not know.

Garbage collection is a good thing for some programs, but a bad thing for other kinds of programs.  I think the C, C++, and Rust developers see "garbage collection", and don't take a second look.  If D was better at being @nogc friendly, out of the box, that would help -- but it would take a bit of an awareness campaign to spread the word.

The syntax has grown a bit, and somewhat awkwardly.  Maybe something to make the syntax less unwieldy.  (I don't think this causes acceptance impedance, though.  It's one of those things that gets discovered over time. C++ is also suffering from ceremonious syntax bloat because the unqualified defaults are wrong due to historical evolutionary reasons.)

To borrow what I've seen from another D developer...

private Handle foo_;
public @property inout(Handle) foo() nothrow pure @safe @nogc return inout {
   return foo_;
}

On Wednesday, 2 September 2020 at 01:49:23 UTC, Eljay wrote:
> C++ is also suffering from ceremonious syntax bloat because the unqualified defaults are wrong due to historical evolutionary reasons.)

Mastering C++ is also very timeconsuming, it relies on the pervasive adoption it has as a framework language + regular updates. C++20 and beyond brings large changes that are likely to renew interest ( modules, concepts, ranges ). I believe such changes work for C++ as compilers give developers the ability to work with older language versions and those are being maintained. So nobody are forced to upgrade. You can freeze your current project on C++14 and adopt C++2a on new projects.

According to github stats, only Go and C++ appears to be growing? Rust has been stagnant since 2014 on github?

Most languages seem to hit a plateu or a ceiling after a few years. The dominant language in each use scenario appears to take the long term growth. So javascript, python, go and c++ appears to be the ones with momentum on github.

On Wednesday, 2 September 2020 at 05:50:39 UTC, Ola Fosheim Grøstad wrote:
> According to github stats, only Go and C++ appears to be growing? Rust has been stagnant since 2014 on github?

If we look at "stars", then Rust had growth from 2013 through 2018 and then it might seem to swing at a plateau of 1%. Go has a more linear growth from 2012, but might flatten out at 10%. C++ has linear growth since 2014, reaching 7%. Too much noise to judge smaller languages, but Julia, Crystal and Nim appears to quickly attract a small following, but no clear growth after that. Sadly D isn't present on this chart.

https://madnight.github.io/githut/#/stars/2020/2

Python is seeing steady growth, reaching 14%. Might be the end of the growth curve. Java+Kotlin has been fairly stable at 11%. C# has hit a plateau in 2019 at 3.5%. Dart quickly hit a plateau at 0.75%. Likewise, Swift had a peak in 2016 at 6%, but enthusiasm appears to have been lost and it is flattening out at 2%.

On Tue, 2020-09-01 at 18:49 +0000, Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:
> > I didn't quite understand that sentence. What is the problem with the current design that prevents D from gaining momentum?
> 
> And of course memory management, which is constantly brought up by ex-D users:
> 
> https://www.osnews.com/story/132286/rust-1-46-0-released/#comments
> 
> Probably the issue with most impact on adoption.

And D without garbage collection would create a pool of ex-D programmers saying "if only D had stuck to it's guns with garbage collection instead of being bullied into a position by C++ and Rust lovers who aren't going to use D anyway."

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wed, 2020-09-02 at 05:50 +0000, Ola Fosheim Grøstad via Digitalmars-d wrote:
> 
[…]
> According to github stats, only Go and C++ appears to be growing? Rust has been stagnant since 2014 on github?

Perhaps because GitHub is not the only choice of backup and marketing platform for what is a *distributed* version control tool. I can't imagine BitBucket is a player, but GitLab definitely is.

> Most languages seem to hit a plateu or a ceiling after a few years. The dominant language in each use scenario appears to take the long term growth. So javascript, python, go and c++ appears to be the ones with momentum on github.

Which is fine, and not a problem.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wednesday, 2 September 2020 at 08:43:29 UTC, Russel Winder wrote:
> Perhaps because GitHub is not the only choice of backup and marketing platform for what is a *distributed* version control tool.

There certainly is a bias towards personal projects on github, but then again, that would be an indicator of genuine interest. Not sure if the trends would differ significantly if you included other repos.

Although, some bias might be peculiar to a specific eco system. E.g. Swift users might find that Apple now has enough built in for them so they look less for external libraries. C# and Java are probably underrepresented because of enterprises favouring closed source.

On Wednesday, 2 September 2020 at 01:49:23 UTC, Eljay wrote:
>
> Some obstacles as I see them are:
>   * no corporate/government/academic sponsor backing the language
>   * garbage collection
>

The biggest mistakes of D is not that it is garbage collected but that it painted itself into a corner requiring a tracing GC which prevents it from using other GC methods.

Either a language is garbage collected which means the runtime/compiler takes care of the memory management or it has manual memory management. Supporting both is in my opinion not realistic because designing libraries than can work in any environment is too complicated. This is an active choice that the library author must take if automatic memory management should be used or not.

You could say that in that case all D libraries must change to using manual memory management so that it can work in any environment. However, this also affects the design of the interfaces and without garbage collection it will be prone for more memory bugs. Also I'm not sure anybody is up to the task rewriting entire runtime/phobos to use manual memory management.

I think that the work towards @nogc is a waste of time. @nogc environments are very specialized and there programmers tend to use their own special libraries as well for full control. The work should be focused towards plug and play GC and reference counting.

On Wednesday, 2 September 2020 at 08:40:27 UTC, Russel Winder wrote:
> And D without garbage collection would create a pool of ex-D programmers saying "if only D had stuck to it's guns with garbage collection instead of being bullied into a position by C++ and Rust lovers who aren't going to use D anyway."

Yes.

But there is a difference between 1) having an ecosystem where many libraries and frameworks rely on stop-the-world-GC 2) having the option of using GC in application code (or maybe just in unit tests).

It is possible to market a low-level programming GC strategy, if it is geared towards that specific use scenario.

Especially if you consider mixed use, e.g. where the application use GC during initialization. But in those cases you might want the gaps on the GC heap to be available for malloc, or run compaction after initialization.

Or just to have GC available for testing frameworks.

On Wed, 2020-09-02 at 09:06 +0000, IGotD- via Digitalmars-d wrote: […]
> 
> I think that the work towards @nogc is a waste of time. @nogc environments are very specialized and there programmers tend to use their own special libraries as well for full control. The work should be focused towards plug and play GC and reference counting.

If D can move to be both GC and non-GC then fine, but for me D is a GC language.

C, C++, and Rust folk (who are the bulk of the anti-GC community) are already firmly anti-D – I suspect no amount of non-GC D is going to change their minds as to what D is as a programming language.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk