• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (12/12) Jan 26 2018 While this analysis of language popularity on Github is
• Benny (14/17) Jan 26 2018 What i found interesting is the comparison between the "newer"
• John Gabriele (4/16) Jan 26 2018 One niche I could see D establishing some popularity is in
• Paulo Pinto (5/24) Jan 26 2018 With GNOME in the process of adopting Rust, I don't have big
• John Gabriele (7/16) Jan 26 2018 With Rust's extra complexity (over D) of ownership/borrowing,
• DanielG (5/9) Jan 26 2018 Adding to that, it was comments like this on the Rust reddit
• Russel Winder (49/57) Jan 28 2018 Being in the middle of rewriting a C++/GTK+ application in both Rust
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (10/22) Jan 26 2018 Yes, those stats are interesting too, but Go seems to do much
• rjframe (10/14) Jan 27 2018 If you use an IDE or analysis/lint tool, you'll get type checking. The
• Ola Fosheim Grostad (6/8) Jan 27 2018 You need to use a type checker to get type checking... No
• rjframe (10/18) Jan 27 2018 My point is that the interpreter ignores information that I give it, whe...
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (9/25) Jan 28 2018 The reference interpreter doesn't make much use of static type
• rjframe (4/13) Jan 28 2018 I should be specific about speaking of the reference implementation. I
• aberba (30/41) Jan 27 2018 Even vala? You have no idea what the guys at elementary.io are
• bachmeier (6/10) Jan 27 2018 The community will have to do this. If Walter and Andrei were
• aberba (15/26) Jan 30 2018 They are part of the community. I'm not saying Andrei or Walter
• bachmeier (14/25) Jan 30 2018 But who's going to pay? I don't think anyone would object to
• aberba (3/14) Jan 30 2018 Is the foundation allowed to publicise its financial status as an
• rjframe (4/6) Jan 30 2018 It's required to file with the IRS, and those filings are public.
• Jonathan Marler (1/1) Jan 26 2018 Very cool stuff, thanks for sharing.
• Michael (17/29) Jan 28 2018 I find it fascinating that C# is in the "languages to avoid"
• Michael (3/13) Jan 28 2018 Oh, I had confused Objective-C with C# in that graph. Forget the
• bachmeier (12/17) Jan 28 2018 I'd say Julia is getting a lot more attention than Rust or Go for
• Russel Winder (25/40) Jan 28 2018 I am still not sure Julia is getting traction outside a few
• Michael (10/27) Jan 28 2018 I wasn't trying to relate these two sections. My point above was
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (5/7) Jan 28 2018 I guess some go to Rust after working with Go, but the transition
• jmh530 (7/14) Jan 28 2018 It would probably be informative to get the raw data and see how
• Jonathan M Davis (10/25) Jan 28 2018 It would be interesting to know, but I question how valid the conclusion...
• jmh530 (5/15) Jan 28 2018 I don't deny that there are limitations to the data. At best, it
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (3/6) Jan 29 2018 Sure, but I don't think there are enough D github-repositories to
• jmh530 (5/12) Jan 30 2018 Small sample size problem makes me think of Bayesian
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (11/17) Jan 30 2018 Yes, I think you need quite a lot of users to get enough github
• Russel Winder (15/19) Jan 29 2018 On Mon, 2018-01-29 at 03:22 +0000, Ola Fosheim Gr=C3=B8stad via Digitalm...
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (10/23) Jan 30 2018 Grounded Theory cannot be used for trend analysis though.
• Russel Winder (13/14) Jan 31 2018 On Tue, 2018-01-30 at 17:26 +0000, Ola Fosheim Gr=C3=B8stad via Digitalm...
• Michael (7/14) Jan 29 2018 I would hazard a guess that Go is likely the language they settle
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (3/8) Jan 30 2018 That could be, many have Python as a secondary high level
• Paulo Pinto (18/56) Jan 28 2018 This has been mentioned multiple times, D really needs some kind
• Laeeth Isharc (104/120) Jan 28 2018 That's what you would expect, because D is a very ambitious
• Russel Winder (86/200) Jan 29 2018 On Sun, 2018-01-28 at 18:54 +0000, Laeeth Isharc via Digitalmars-d
• Mafi (5/16) Jan 29 2018 What would you say are the most important differences between dub
• Russel Winder (25/29) Jan 30 2018 The single most important thing is that Cargo stores source on a per
• rjframe (32/54) Jan 30 2018 Are you sure? Every project on my PC places the build files in
• Benny (20/42) Jan 30 2018 Right side:
• rjframe (14/23) Jan 30 2018 Thanks. I wish that was easier to find though. I still don't see how to
• Russel Winder (42/78) Feb 01 2018 I see the source of the dependencies both in ~/.dub/packages and in the
• Jacob Carlborg (13/19) Feb 01 2018 I'm wondering if this might be different versions of Dub behaving
• Atila Neves (12/26) Feb 02 2018 Whether it's .a or .so depends on the dependent package being
• Russel Winder (23/34) Feb 02 2018 I think that is one of my points, the package source downloaded from
• Atila Neves (10/39) Feb 02 2018 Not quite. There's an extra step and when linking with a static
• Joakim (24/35) Feb 01 2018 I thought this was a killer anecdote about maybe the first
• aberba (23/150) Jan 30 2018 That's one big potential mistake. Enterprises care about making
• rjframe (26/48) Jan 30 2018 Well... if the goal is merely number of programmers, getting enterprises...
• John Gabriele (16/48) Jan 30 2018 I get the impression that a wave is coming (or is already here)
• Laeeth Isharc (86/258) Jan 30 2018 Who said anything about chasing after companies? There's not much
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (16/19) Jan 30 2018 Not sure what you mean by principles, Algol languages (the class
• TooHuman (13/30) Jan 30 2018 You're absolutely right in that, for a language like D with such
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (7/16) Jan 28 2018 I don't think the data suggests that? A small dip, perhaps, as it

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

While this analysis of language popularity on Github is 
enlightening:

http://www.benfrederickson.com/ranking-programming-languages-by-github-users/

I found the older analysis of how programmers transition (or 
adopt new languages) more interesting:

https://blog.sourced.tech/post/language_migrations/

Like how people move from Rust to Go. And from Go to Python:

https://blog.sourced.tech/post/language_migrations/sum_matrix_22lang_eig.svg


Also the growth of Java is larger than I would anticipate:

https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png

Granted, Java has gotten quite a few convenience features over 
the years.

Benny <benny.luypaert rhysoft.com> writes:

On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad 
wrote:
 While this analysis of language popularity on Github is 
 enlightening:

 http://www.benfrederickson.com/ranking-programming-languages-by-github-users/

What i found interesting is the comparison between the "newer" 
languages and D ( see the reddit thread ).

9   Go      4.1022
15  Kotlin  1.2798
18  Rust    0.7317
35  Julia   0.0900
46  Vala    0.0665
50  Crystal 0.0498
53  D       0.047%

While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), Go 
( Google ).
Even Vala and Crystal are ranked higher then D.

John Gabriele <jgabriele fastmail.fm> writes:

On Friday, 26 January 2018 at 17:24:54 UTC, Benny wrote:
 What i found interesting is the comparison between the "newer" 
 languages and D ( see the reddit thread ).

  9  Go      4.1022
 15  Kotlin  1.2798
 18  Rust    0.7317
 35  Julia   0.0900
 46  Vala    0.0665
 50  Crystal 0.0498
 53  D       0.047%

 While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), 
 Go ( Google ).
 Even Vala and Crystal are ranked higher then D.

One niche I could see D establishing some popularity is in 
GNU/Linux GTK desktop apps. Especially now that GDC will be part 
of GCC.

Paulo Pinto <pjmlp progtools.org> writes:

On Friday, 26 January 2018 at 18:46:12 UTC, John Gabriele wrote:
 On Friday, 26 January 2018 at 17:24:54 UTC, Benny wrote:
 What i found interesting is the comparison between the "newer" 
 languages and D ( see the reddit thread ).

  9  Go      4.1022
 15  Kotlin  1.2798
 18  Rust    0.7317
 35  Julia   0.0900
 46  Vala    0.0665
 50  Crystal 0.0498
 53  D       0.047%

 While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), 
 Go ( Google ).
 Even Vala and Crystal are ranked higher then D.

 One niche I could see D establishing some popularity is in 
 GNU/Linux GTK desktop apps. Especially now that GDC will be 
 part of GCC.

With GNOME in the process of adopting Rust, I don't have big 
hopes for it.

https://wiki.gnome.org/Hackfests/Rust2017

https://wiki.gnome.org/Hackfests/Rust2017-2

John Gabriele <jgabriele fastmail.fm> writes:

On Friday, 26 January 2018 at 20:08:15 UTC, Paulo Pinto wrote:
 On Friday, 26 January 2018 at 18:46:12 UTC, John Gabriele wrote:
 One niche I could see D establishing some popularity is in 
 GNU/Linux GTK desktop apps. Especially now that GDC will be 
 part of GCC.

 With GNOME in the process of adopting Rust, I don't have big 
 hopes for it.

 https://wiki.gnome.org/Hackfests/Rust2017

 https://wiki.gnome.org/Hackfests/Rust2017-2

With Rust's extra complexity (over D) of ownership/borrowing, 
lifetimes, and no GC, although we may currently see a push for 
more Rust in Gnome for system-level code, I think D may beat it 
for writing *applications*.

I'm planning on learning more D, then trying out GtkD to see how 
it compares with Python + PyGObject for some little apps.

DanielG <simpletangent gmail.com> writes:

On Friday, 26 January 2018 at 20:31:30 UTC, John Gabriele wrote:
 With Rust's extra complexity (over D) of ownership/borrowing, 
 lifetimes, and no GC, although we may currently see a push for 
 more Rust in Gnome for system-level code, I think D may beat it 
 for writing *applications*.

Adding to that, it was comments like this on the Rust reddit 
group that really reinforce my decision to stay far away from 
Rust for desktop app development: 
https://www.reddit.com/r/rust/comments/7gg7lm/what_is_currently_the_best_options_for_gui/dqjo1c4/

Russel Winder <russel winder.org.uk> writes:

On Fri, 2018-01-26 at 20:31 +0000, John Gabriele via Digitalmars-d
wrote:
 [=E2=80=A6]
=20
 With Rust's extra complexity (over D) of ownership/borrowing,=20
 lifetimes, and no GC, although we may currently see a push for=20
 more Rust in Gnome for system-level code, I think D may beat it=20
 for writing *applications*.

Being in the middle of rewriting a C++/GTK+ application in both Rust
and D, both have pluses and minuses.

Documentation, and examples, for both D and Rust, are woefully
inadequate, but Rust is getting better quite rapidly because it has
something of a dedicated workforce.=20

The D and Rust architecture models are surprisingly similar in terms of
mental model, however Rust's current lack of inheritance really is a
pain: currently D wins on this hands down.  The gtk-rs people are
looking to solve this by exposing the internal inheritance mechanism to
the aPI users.

Rust/Cargo win hands down over D/Dub. This is a problem with Dub. One
that seems unlikely to be addressed. This means using SCons and Meson
for D code, which works surprisingly well, and yet has some huge
problems.

D appears to be clumsier than Rust for error handling. I think this may
be that the monad-based approach is working better for me just now. Of
course there are irritants with the monads approach.

(Side bar: The Rust and D bindings are generated from the GTK gir files
which is great, but the C++ API is hand crafted which leads to lots of
inconsistencies with the underlying C API.)

 I'm planning on learning more D, then trying out GtkD to see how=20
 it compares with Python + PyGObject for some little apps.

Where Python and PyGobject (based on gir files) wins is you stop having
to faff around with all the compile time types: the dynamic typing of
Python has many huge benefits for writing GTK+ applications compared to
C++, D, Rust.=20

For my application, I am using GStreamer. The GStreamer core team are
backing Rust since it is the only language they trust with regard to
managing memory. Clearly C is totally inadequate but if you code is in
C you allow Stockholm Syndrome. C++ is also inadequate but more due to
the pointer types being add ons and not really checked. Rust is clearly
far superior to C++ in this respect, at the risk of the borrow checker
sometimes being impossible to satisfy. The GStreamer people refuse to
accept the existence of a garbage collector. On the other hand there is
GStreamerD, but the problem is you have to deduce or infer how to use
the D binding from the C API. And there is no work other than Mike
Wey's in the GtkD suite (*).=20

If the D community think D is a Rust beater for GTK+ applications then
get involved with keeping the GtkD binding up to date, do not assume
Mike will do all the work.



(*) Huge vote of thanks to Mike for continuing to keep the GtkD suite
up to date.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Friday, 26 January 2018 at 17:24:54 UTC, Benny wrote:
 What i found interesting is the comparison between the "newer" 
 languages and D ( see the reddit thread ).

 9   Go      4.1022
 15  Kotlin  1.2798
 18  Rust    0.7317
 35  Julia   0.0900
 46  Vala    0.0665
 50  Crystal 0.0498
 53  D       0.047%

 While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), 
 Go ( Google ).
 Even Vala and Crystal are ranked higher then D.

Yes, those stats are interesting too, but Go seems to do much 
better than Rust. And if the trend is that people move from  Rust 
to Go and from Go to Python it might mean that people might start 
out trying out new languages with performance goals in mind, but 
eventually go for productivity when they realize that they pay a 
fairly high price for those performance gains? Anyway, with 
Python 3.6 you get fairly good type annotation capabilities which 
allows static type checking that  is closing on what you get with 
statically typed languages.  Maybe that is a factor too.

rjframe <dlang ryanjframe.com> writes:

On Sat, 27 Jan 2018 00:32:21 +0000, Ola Fosheim Grøstad wrote:

 ... Anyway, with Python 3.6 you get fairly good
 type annotation capabilities which allows static type checking that  is
 closing on what you get with statically typed languages.  Maybe that is
 a factor too.

If you use an IDE or analysis/lint tool, you'll get type checking. The 
interpreter will happily ignore those annotations.

No complaints here:
```
somevar : int = 'my string'

def func() -> int:
    return 'some string'
func()
```

Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:

On Saturday, 27 January 2018 at 13:56:35 UTC, rjframe wrote:
 If you use an IDE or analysis/lint tool, you'll get type 
 checking. The interpreter will happily ignore those annotations.

You need to use a type checker to get type checking... No 
surprise there, but without standard type annotations the type 
checker isn't all that useful.  Only in past few years have 
typing stubs become available for libraries, and that makes a 
difference,

rjframe <dlang ryanjframe.com> writes:

On Sat, 27 Jan 2018 22:59:17 +0000, Ola Fosheim Grostad wrote:

 On Saturday, 27 January 2018 at 13:56:35 UTC, rjframe wrote:
 If you use an IDE or analysis/lint tool, you'll get type checking. The
 interpreter will happily ignore those annotations.

 
 You need to use a type checker to get type checking... No surprise
 there, but without standard type annotations the type checker isn't all
 that useful.  Only in past few years have typing stubs become available
 for libraries, and that makes a difference,

My point is that the interpreter ignores information that I give it, when 
that information clearly proves that I have a bug. Python 3.6 gives you an 
explicit type system when you want/need it, but stops just short of making 
it actually useful without secondary tools.

Granted, everybody should be using those tools on decent-sized projects 
anyway, but the interpreter shouldn't be ignoring obvious issues. If I 
explicitly label a type, implicit casts/overrides/replacements should not 
be accepted, no matter how dynamic the type system. The feature was 
designed for tools; they failed to design it for programmers as well.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Sunday, 28 January 2018 at 00:31:18 UTC, rjframe wrote:
 On Sat, 27 Jan 2018 22:59:17 +0000, Ola Fosheim Grostad wrote:

 On Saturday, 27 January 2018 at 13:56:35 UTC, rjframe wrote:
 If you use an IDE or analysis/lint tool, you'll get type 
 checking. The interpreter will happily ignore those 
 annotations.

 
 You need to use a type checker to get type checking... No 
 surprise there, but without standard type annotations the type 
 checker isn't all that useful.  Only in past few years have 
 typing stubs become available for libraries, and that makes a 
 difference,

 My point is that the interpreter ignores information that I 
 give it, when that information clearly proves that I have a 
 bug. Python 3.6 gives you an explicit type system when you 
 want/need it, but stops just short of making it actually useful 
 without secondary tools.

The reference interpreter doesn't make much use of static type 
information. I think it makes sense to have separate type 
checkers until this new aspect of Python has reached maturity. 
That doesn't prevent third parties to implement interpreters that 
makes use of type information.

Professionals won't shy away from using additional tools anyway, 
so the only reason to build it into the interpreter is for 
optimization at this point.

rjframe <dlang ryanjframe.com> writes:

On Sun, 28 Jan 2018 11:44:05 +0000, Ola Fosheim Grøstad wrote:

 The reference interpreter doesn't make much use of static type
 information. I think it makes sense to have separate type checkers until
 this new aspect of Python has reached maturity. That doesn't prevent
 third parties to implement interpreters that makes use of type
 information.
 
 Professionals won't shy away from using additional tools anyway, so the
 only reason to build it into the interpreter is for optimization at this
 point.

I should be specific about speaking of the reference implementation. I 
just think comments that look like code (which is basically what this is) 
is always a bad idea.

aberba <karabutaworld gmail.com> writes:

On Friday, 26 January 2018 at 17:24:54 UTC, Benny wrote:
 On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad 
 wrote:
 While this analysis of language popularity on Github is 
 enlightening:

 http://www.benfrederickson.com/ranking-programming-languages-by-github-users/

 What i found interesting is the comparison between the "newer" 
 languages and D ( see the reddit thread ).

 While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), 
 Go ( Google ).
 Even Vala and Crystal are ranked higher then D.

Even vala? You have no idea what the guys at elementary.io are 
doing to get more developers to use Vala and GTK for elementary 
OS (Linux) apps. They are developing an IDE in addition to their 
straight forward Granite toolkit for making app development in 
vala much more easier and productive. They've managed to get over 
70 fully-native apps designed for their OS from independent 
developers since second half of last year, when they launched 
their app center.

I don't know how the D Foundation think or know about growing the 
developer community and tools, but I don't see a good job done in 
that aspect. And...elementary makes less money than D Foundation 
(I think, besides, they don't spend money on their community 
growth... just the obvious "non-technical" stuff).

The committee really need to have a modern approach to this 
community and tools thing.

There have been several complaints about tools, and certain 
important stuff missing in the standard library (HTTP/HTTP2, rpc, 
etc) and no 'official' response or some blog post from them about 
it (whether they even care). Several efforts have been 
made...(the std_* stuff in the dub registry)... still nothing 
much. At least input from committee show they care. I feel like 
its always compiler stuff alone.


Or pay someone good at developer community stuff to take charge. 
I said this some 2 yrs ago (my language about "female" won me 
some insults from some people in the forum, remember? It was 
discussed at the conference with the exception of the idea I was 
trying to communicate). I watched the D 2017 Conference and 
nothing about tools and community growth was discussed (except it 
was not "video-ed"). Unless its not important that much.

bachmeier <no spam.net> writes:

On Saturday, 27 January 2018 at 20:15:51 UTC, aberba wrote:
 There have been several complaints about tools, and certain 
 important stuff missing in the standard library (HTTP/HTTP2, 
 rpc, etc) and no 'official' response or some blog post from 
 them about it (whether they even care).

The community will have to do this. If Walter and Andrei were 
interested in it, they'd have been working on it long ago. They 
have way too much to do the way it is, and as soon as it becomes 
official, there are rules and rules about rules and six levels of 
bureaucracy.

aberba <karabutaworld gmail.com> writes:

On Sunday, 28 January 2018 at 00:47:23 UTC, bachmeier wrote:
 On Saturday, 27 January 2018 at 20:15:51 UTC, aberba wrote:
 There have been several complaints about tools, and certain 
 important stuff missing in the standard library (HTTP/HTTP2, 
 rpc, etc) and no 'official' response or some blog post from 
 them about it (whether they even care).

 The community will have to do this.

They are part of the community. I'm not saying Andrei or Walter 
should write an http/https2, json,  etc.
  lib. They need to actively help build and grow the 
community/workforce that collectively make those things happen. 
Or pay someone part-time or full time to do that.

 If Walter and Andrei were interested in it, they'd have been 
 working on it long ago. They have way too much to do the way it 
 is,

They speak for themselves.

 and as soon as it becomes official, there are rules and rules 
 about rules and six levels of bureaucracy.

I did say those things are missing in the standard library but it 
doesn't have to be in Phobos to receive upstream support.


There are a list of things developers need to build killer apps 
and web services in D. The larger the workforce,  the more likely 
we get people to contribute in those areas (theory,  code, tools, 
  documentation,  tutorials,  libraries, promotions, solutions, 
etc). And those things are equally important in every popular 
programming language today to continue to gain wider adoption.

bachmeier <no spam.net> writes:

On Tuesday, 30 January 2018 at 08:32:41 UTC, aberba wrote:
 On Sunday, 28 January 2018 at 00:47:23 UTC, bachmeier wrote:
 The community will have to do this.

 They are part of the community. I'm not saying Andrei or Walter 
 should write an http/https2, json,  etc.
  lib. They need to actively help build and grow the 
 community/workforce that collectively make those things happen. 
 Or pay someone part-time or full time to do that.

But who's going to pay? I don't think anyone would object to 
paying someone to write libraries - it worked well for languages 
like Java - but I'm not aware of a pot of money to do that. Also, 
and I don't mean this in a bad way, I think Walter and Andrei are 
skilled at tasks other than building a community. Everyone has 
their own set of interests, and for them, it's not building a 
community. Just my observation of course.

 If Walter and Andrei were interested in it, they'd have been 
 working on it long ago. They have way too much to do the way 
 it is,

 They speak for themselves.

Except that their involvement would mean all decisions go through 
them, and things already move slowly enough on the 
language/compiler/Phobos that it would be a disaster to add more 
to their todo lists. Not only would it make it impossible to get 
anything done on those libraries, it would slow down everything 
else they're involved with as well.

aberba <karabutaworld gmail.com> writes:

On Tuesday, 30 January 2018 at 20:56:22 UTC, bachmeier wrote:
 On Tuesday, 30 January 2018 at 08:32:41 UTC, aberba wrote:
 [...]

 But who's going to pay? I don't think anyone would object to 
 paying someone to write libraries - it worked well for 
 languages like Java - but I'm not aware of a pot of money to do 
 that. Also, and I don't mean this in a bad way, I think Walter 
 and Andrei are skilled at tasks other than building a 
 community. Everyone has their own set of interests, and for 
 them, it's not building a community. Just my observation of 
 course.

Is the foundation allowed to publicise its financial status as an 
NGO based on US laws?

 [...]

rjframe <dlang ryanjframe.com> writes:

On Tue, 30 Jan 2018 20:59:16 +0000, aberba wrote:

 Is the foundation allowed to publicise its financial status as an NGO
 based on US laws?


It's required to file with the IRS, and those filings are public.

The 2016 990-EZ filing:
http://990s.foundationcenter.org/990_pdf_archive/475/475352856/475352856_201612_990EZ.pdf

Jonathan Marler <johnnymarler gmail.com> writes:

Very cool stuff, thanks for sharing.

Michael <michael toohuman.io> writes:

On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad 
wrote:
 While this analysis of language popularity on Github is 
 enlightening:

 http://www.benfrederickson.com/ranking-programming-languages-by-github-users/

 I found the older analysis of how programmers transition (or 
 adopt new languages) more interesting:

 https://blog.sourced.tech/post/language_migrations/

 Like how people move from Rust to Go. And from Go to Python:

 https://blog.sourced.tech/post/language_migrations/sum_matrix_22lang_eig.svg


 Also the growth of Java is larger than I would anticipate:

 https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png

 Granted, Java has gotten quite a few convenience features over 
 the years.


section, because from my perspective it's receiving more and more 
adoption as the modern alternative to Java, in a way that Go and 
Rust are not. Different markets and all of that. So I can't see 

(though I don't use it myself).

I do worry that, having been using D for about 3 1/2 years now, 
that the perceptions of D outside of this community don't seem to 
be changing much. It does seem to make a huge difference to have 
a big company behind a language, purely for the "free 
advertisement". Most people at my university, outside of the 
computer science department, that are using languages like Python 
and R and MATLAB the most, are very aware of Rust and Go, but not 
D. I wonder if we do need to pay more attention to attracting new 
users just to get people talking about it.

Michael <michael toohuman.io> writes:

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
 On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad 
 wrote:
 [...]


 section, because from my perspective it's receiving more and 
 more adoption as the modern alternative to Java, in a way that 
 Go and Rust are not. Different markets and all of that. So I 

 in popularity (though I don't use it myself).

 [...]


first part of my previous post.

bachmeier <no spam.net> writes:

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
 Most people at my university, outside of the computer science 
 department, that are using languages like Python and R and 
 MATLAB the most, are very aware of Rust and Go, but not D.

I'd say Julia is getting a lot more attention than Rust or Go for 
those users. And rightfully so.

 I wonder if we do need to pay more attention to attracting new 
 users just to get people talking about it.

I'm not sure why those users would be interested in D at the 
moment. D presents itself as a C++ replacement, discussions are 
all about low-level stuff, garbage collection, and efficiency, 
and new users are told to use Dub and learn about Git submodules. 
That's not ever going to appeal to the R and Matlab crowd. I have 
gotten others to start using D, and it was quite easy. Just make 
an R package containing D code, they install it, and then they 
call D functions from R. Few in this community understand that 
style of programming though.

Russel Winder <russel winder.org.uk> writes:

On Sun, 2018-01-28 at 15:36 +0000, bachmeier via Digitalmars-d wrote:
=20

[=E2=80=A6]
 I'd say Julia is getting a lot more attention than Rust or Go for=20
 those users. And rightfully so.

I am still not sure Julia is getting traction outside a few
communities. Python still seems to be the language of choice in data
analysis visualisation.

 I wonder if we do need to pay more attention to attracting new=20
 users just to get people talking about it.

=20
 I'm not sure why those users would be interested in D at the=20
 moment. D presents itself as a C++ replacement, discussions are=20
 all about low-level stuff, garbage collection, and efficiency,=20
 and new users are told to use Dub and learn about Git submodules.=20
 That's not ever going to appeal to the R and Matlab crowd. I have=20
 gotten others to start using D, and it was quite easy. Just make=20
 an R package containing D code, they install it, and then they=20
 call D functions from R. Few in this community understand that=20
 style of programming though.

Dub looked like it was going to be good, but somehow development
stopped and it fails to deliver compared to Cargo.  Although Cargo is
language specific, and thus inferior to SCons, Meson, CMake, etc., it
works very well indeed for building and installing Rust codes. The Go
system works well in the context of a workspace structured system.

Compared to the Rust and Go community, D is lacking a package system
and build system that really works. Also, a JetBrains IDE for D is
absent =E2=80=93 though Samael and Francis are trying very hard to improve
this. The problem is though that JetBrains are unlikely to pick up the
plugin and make it official in the way that they did Rust and Go.
Perhaps the Clojure plugin model as per Cursive might be in order, i.e.
people pay an annual subscription for it within the free to use
IntelliJ IDEA.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

Michael <michael toohuman.io> writes:

On Sunday, 28 January 2018 at 15:36:17 UTC, bachmeier wrote:
 On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
 Most people at my university, outside of the computer science 
 department, that are using languages like Python and R and 
 MATLAB the most, are very aware of Rust and Go, but not D.

 I'd say Julia is getting a lot more attention than Rust or Go 
 for those users. And rightfully so.

I wasn't trying to relate these two sections. My point above was 
that people who don't really work with systems languages were 
still widely aware of the existence of new languages, while D 
remains relatively obscure.

 I wonder if we do need to pay more attention to attracting new 
 users just to get people talking about it.

 I'm not sure why those users would be interested in D at the 
 moment. D presents itself as a C++ replacement, discussions are 
 all about low-level stuff, garbage collection, and efficiency, 
 and new users are told to use Dub and learn about Git 
 submodules. That's not ever going to appeal to the R and Matlab 
 crowd. I have gotten others to start using D, and it was quite 
 easy. Just make an R package containing D code, they install 
 it, and then they call D functions from R. Few in this 
 community understand that style of programming though.

But D is fighting against Rust and Go, and struggling to pull any 
attention away from either. Go has found its niche, and has 
settled pretty well, but it has not been overwhelmingly adopted 
by the whole target audience. Rust, on the other hand, seems to 
be picking up those who have left Go.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Sunday, 28 January 2018 at 23:09:00 UTC, Michael wrote:
 by the whole target audience. Rust, on the other hand, seems to 
 be picking up those who have left Go.

I guess some go to Rust after working with Go, but the transition 
matrix linked above suggests that the trend has been that people 
give up on Rust and try out Go then Python... Of course, with so 
little data things are uncertain and can change.

jmh530 <john.michael.hall gmail.com> writes:

On Monday, 29 January 2018 at 03:22:54 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 28 January 2018 at 23:09:00 UTC, Michael wrote:
 by the whole target audience. Rust, on the other hand, seems 
 to be picking up those who have left Go.

 I guess some go to Rust after working with Go, but the 
 transition matrix linked above suggests that the trend has been 
 that people give up on Rust and try out Go then Python... Of 
 course, with so little data things are uncertain and can change.

It would probably be informative to get the raw data and see how 
the transition matrix looks for D. Are people (or rather github 
users) coming to D from C/C++ or from other languages. Would help 
inform strategy for getting new users or why people from certain 
languages are less likely to try D.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

On Monday, January 29, 2018 04:18:12 jmh530 via Digitalmars-d wrote:
 On Monday, 29 January 2018 at 03:22:54 UTC, Ola Fosheim Grøstad

 wrote:
 On Sunday, 28 January 2018 at 23:09:00 UTC, Michael wrote:
 by the whole target audience. Rust, on the other hand, seems
 to be picking up those who have left Go.

 I guess some go to Rust after working with Go, but the
 transition matrix linked above suggests that the trend has been
 that people give up on Rust and try out Go then Python... Of
 course, with so little data things are uncertain and can change.

 It would probably be informative to get the raw data and see how
 the transition matrix looks for D. Are people (or rather github
 users) coming to D from C/C++ or from other languages. Would help
 inform strategy for getting new users or why people from certain
 languages are less likely to try D.

It would be interesting to know, but I question how valid the conclusions
are just getting information from github like that. For instance, I came
from C++ to D. However, I never used github before D's developement moved to
github, and their methodology would show me as someone who used D almost
exclusively and who did not switch from any other language. So, while I'm
sure that some valid conclusions can be taken from the data, it's going to
be skewed by the fact that not everything a programmer does or has done ends
up on github.

- Jonathan M Davis

jmh530 <john.michael.hall gmail.com> writes:

On Monday, 29 January 2018 at 04:58:49 UTC, Jonathan M Davis 
wrote:
 It would be interesting to know, but I question how valid the 
 conclusions are just getting information from github like that. 
 For instance, I came from C++ to D. However, I never used 
 github before D's developement moved to github, and their 
 methodology would show me as someone who used D almost 
 exclusively and who did not switch from any other language. So, 
 while I'm sure that some valid conclusions can be taken from 
 the data, it's going to be skewed by the fact that not 
 everything a programmer does or has done ends up on github.

 - Jonathan M Davis

I don't deny that there are limitations to the data. At best, it 
would be telling you the transition of github users over a 
specific period.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Monday, 29 January 2018 at 05:21:14 UTC, jmh530 wrote:
 I don't deny that there are limitations to the data. At best, 
 it would be telling you the transition of github users over a 
 specific period.

Sure, but I don't think there are enough D github-repositories to 
get decent quantitative analysis... Maybe a qualitative analysis.

jmh530 <john.michael.hall gmail.com> writes:

On Tuesday, 30 January 2018 at 07:38:05 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 29 January 2018 at 05:21:14 UTC, jmh530 wrote:
 I don't deny that there are limitations to the data. At best, 
 it would be telling you the transition of github users over a 
 specific period.

 Sure, but I don't think there are enough D github-repositories 
 to get decent quantitative analysis... Maybe a qualitative 
 analysis.

Small sample size problem makes me think of Bayesian 
analysis...though I suppose there's a bigger problem if D doesn't 
have enough github repositories.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Tuesday, 30 January 2018 at 12:35:21 UTC, jmh530 wrote:
 Sure, but I don't think there are enough D github-repositories 
 to get decent quantitative analysis... Maybe a qualitative 
 analysis.

 Small sample size problem makes me think of Bayesian 
 analysis...though I suppose there's a bigger problem if D 
 doesn't have enough github repositories.

Yes, I think you need quite a lot of users to get enough github 
repositories. Not sure what the percentage would be, maybe 1 out 
50 users or less are active on github?

Of course, the Rust analysis might be a bit off too, because it 
is common for enthusiasts to try out and leave young languages. 
There might be a significant difference between hobby and 
professional users too.

Anyway, I think the "pagerank" transition analysis is 
interesting. It provides some insights into dynamics, and also 
which transitions don't happen give us something to think about.

Russel Winder <russel winder.org.uk> writes:

On Mon, 2018-01-29 at 03:22 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-
d wrote:
[=E2=80=A6]
 I guess some go to Rust after working with Go, but the transition=20
 matrix linked above suggests that the trend has been that people=20
 give up on Rust and try out Go then Python... Of course, with so=20
 little data things are uncertain and can change.

I think this is an important point. There was some interesting data
found, some hypotheses possible, but without further experimentation
and/or formal use of Grounded Theory exploration, all commentary is
speculation and opinion.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Monday, 29 January 2018 at 10:12:04 UTC, Russel Winder wrote:
 On Mon, 2018-01-29 at 03:22 +0000, Ola Fosheim Grøstad via 
 Digitalmars-
 d wrote:
 […]
 I guess some go to Rust after working with Go, but the 
 transition matrix linked above suggests that the trend has 
 been that people give up on Rust and try out Go then Python... 
 Of course, with so little data things are uncertain and can 
 change.

 I think this is an important point. There was some interesting 
 data found, some hypotheses possible, but without further 
 experimentation and/or formal use of Grounded Theory 
 exploration, all commentary is speculation and opinion.

Grounded Theory cannot be used for trend analysis though. 
Certainly you could use quantitative data for sampling some users 
(using some kind of stratification) and interview them and then 
use GT to try to capture themes in the psychology of people who 
move from one language to another. So yes, more interesting, but 
you wouldn't learn more about the actual trend.

It is like the difference between knowing why waves build up in 
the ocean (qualitative) and knowing how many large waves we have 
and where they tend to occur (quantitative). Both are interesting.

Russel Winder <russel winder.org.uk> writes:

On Tue, 2018-01-30 at 17:26 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-
d wrote:
[=E2=80=A6]
 Grounded Theory cannot be used for trend analysis though.=20

[=E2=80=A6]

Quite right, good point.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

Michael <michael toohuman.io> writes:

On Monday, 29 January 2018 at 03:22:54 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 28 January 2018 at 23:09:00 UTC, Michael wrote:
 by the whole target audience. Rust, on the other hand, seems 
 to be picking up those who have left Go.

 I guess some go to Rust after working with Go, but the 
 transition matrix linked above suggests that the trend has been 
 that people give up on Rust and try out Go then Python... Of 
 course, with so little data things are uncertain and can change.

I would hazard a guess that Go is likely the language they settle 
on for whatever task required something more low-level like 
Rust/Go(/D? =[ ) and that they move to Python for the kinds of 
scripting tasks that follow development of something in the 
previous languages.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Monday, 29 January 2018 at 22:28:35 UTC, Michael wrote:
 I would hazard a guess that Go is likely the language they 
 settle on for whatever task required something more low-level 
 like Rust/Go(/D? =[ ) and that they move to Python for the 
 kinds of scripting tasks that follow development of something 
 in the previous languages.

That could be, many have Python as a secondary high level 
language.

Paulo Pinto <pjmlp progtools.org> writes:

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
 On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad 
 wrote:
 While this analysis of language popularity on Github is 
 enlightening:

 http://www.benfrederickson.com/ranking-programming-languages-by-github-users/

 I found the older analysis of how programmers transition (or 
 adopt new languages) more interesting:

 https://blog.sourced.tech/post/language_migrations/

 Like how people move from Rust to Go. And from Go to Python:

 https://blog.sourced.tech/post/language_migrations/sum_matrix_22lang_eig.svg


 Also the growth of Java is larger than I would anticipate:

 https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png

 Granted, Java has gotten quite a few convenience features over 
 the years.


 section, because from my perspective it's receiving more and 
 more adoption as the modern alternative to Java, in a way that 
 Go and Rust are not. Different markets and all of that. So I 

 in popularity (though I don't use it myself).

 I do worry that, having been using D for about 3 1/2 years now, 
 that the perceptions of D outside of this community don't seem 
 to be changing much. It does seem to make a huge difference to 
 have a big company behind a language, purely for the "free 
 advertisement". Most people at my university, outside of the 
 computer science department, that are using languages like 
 Python and R and MATLAB the most, are very aware of Rust and 
 Go, but not D. I wonder if we do need to pay more attention to 
 attracting new users just to get people talking about it.

This has been mentioned multiple times, D really needs some kind 
of killer application.

On my line of work having Go on the skills list is slowly 
becoming a requirement, due to Docker and Kubernetes adoption on 
cloud infrastructures.

The new OpenGL debugger for Android from Google has been 
re-written in Go.

Go and Rust are also having a relevant role in Fuchsia, e.g. the 
TCP/IP stack is 100% Go code.

The new regexp engine from Visual Studio Code is written in Rust.

The Go plugin for Visual Studio Code is written by Microsoft 
themselves.

D has PowerNex as an example OS, but Redox looks more pleasing to 
the eye, in what concerns attracting new developers to the 
project.

Just wondering if mir or easier GPGPU programming could be that 
killer application.

Laeeth Isharc <laeeth laeeth.com> writes:

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
 I do worry that, having been using D for about 3 1/2 years now, 
 that the perceptions of D outside of this community don't seem 
 to be changing much. It does seem to make a huge difference to 
 have a big company behind a language, purely for the "free 
 advertisement". Most people at my university, outside of the 
 computer science department, that are using languages like 
 Python and R and MATLAB the most, are very aware of Rust and 
 Go, but not D. I wonder if we do need to pay more attention to 
 attracting new users just to get people talking about it.

That's what you would expect, because D is a very ambitious 
language, which means its natural user base is much more spread 
out and less highly concentrated.  And beyond that, most code is 
enterprise code that's closed source, and whilst the web guys 
talk a lot and influence the culture, enterprise guys talk much 
less and just do their thing quietly.  Even in our world, how 
often do you see the people using D get involved in forum 
discussions?  Sociomantic, Weka, Ebay, and so on.  (Or Microsoft 
- did you know that D was used in their COM team?  They didn't 
exactly send out a press release...)  A little bit, but only a 
little in relation to their use of the language.  If you're 
trying to accomplish something in a representative enterprise 
context with lean resources, you don't have much time to talk 
about what you are doing.

If you want to draw people to the language (and, honestly, I 
wonder why it matters so much to many here - it's clearly taking 
hold, has momentum and will continue to grow for decades; an 
acorn will become an oak tree, and fretting about how much it's 
grown in the past year might be missing the point, so long as 
it's healthy enough), why not just focus on both improving the 
language itself (pull requests, documentation) and on 
accomplishing something useful and worth doing with it?

Of course there are the usual trolls who don't seem to write much 
D, but seem to be drawn like vampires to the energy of those who 
do.  Sad.




On Sunday, 28 January 2018 at 17:23:12 UTC, Paulo Pinto wrote:
 This has been mentioned multiple times, D really needs some 
 kind of killer application.

Why?

It's a generalist language for getting stuff done in an age where 
people have succumbed so much to Stockholm Syndrome that they 
think it's a positive thing in a language that you can only use 
it to do something special.  Yet trends in performance and 
performance demands point to the rising importance of efficiency 
(and I suspect there will be a return to the recognition of the 
importance of being a generalist - in programming, as in other 
fields).  There was a tweet by the author of Musl libc observing 
that software today runs slower than software twenty years ago, 
and linking the bloat to the insane pressure to maximise CPU 
performance over all else.  The era of that kind of ruthless 
optimization is over because it's not the only thing that 
matters, and we start to see the price of it.  And generalism - 
in a dynamic business environment, there's considerable value to 
have capabilities that aren't adapted to particular narrow skills 
when what you need is always changing and may be unknown even to 
you.

My generation was privileged because very quickly if you wanted 
to get anything interesting done you had to learn assembly 
language (maybe write your own assembler or disassembler), had to 
learn a bit about hardware, and could never pretend the CPU was 
this perfect platonic abstraction.  And for a while that changed, 
but I think the past is returning again, as it often does.

So I see a value in hiring hacker / generalist types who can 
figure things out.  For example:

https://hackaday.com/2017/01/26/a-personal-fight-against-the-modern-laptop/
https://www.youtube.com/watch?v=Fzmm87oVQ6c

Back in 2007, most finance types would have said how completely 
impracticable and unreasonable.  But I say, with GK Chesterton, 
that "all progress depends on the unreasonable man".  And someone 
like that doesn't succumb to helplessness once they are outside 
of their shiny IDE, knows that in the end everything is just 
code, and you can change it if you want to, and there is 
strategic value from building organisational capabilities from 
hiring such people.  Usually I'm a couple of years ahead, and I 
think others will follow.  If you hold a contrarian point of 
view, you know you're right when surprises start coming in your 
direction, and people still can't see it.  And I think that's 
been the case since 2014.

Anyway - so D is a general purpose language, and I think we are 
likely seeing a nascent return in recognizing the value of 
generalist tools and people.

 On my line of work having Go on the skills list is slowly 
 becoming a requirement, due to Docker and Kubernetes adoption 
 on cloud infrastructures.

That's great.  Walter says that good code should look good on the 
page, and Go code looks nice enough.  It's got nice network and 
infra libraries, as you say.  But why would the adoption of Go be 
bad for D?  I think it's great for D because after a period of 
stagnation it gets people open to newer languages, and on the 
other hand the gap between the spirit of Go and D isn't that far 
(GC, clean code, native target) even if they don't have generics. 
  It's a big world - both D and Go can succeed, and the success of 
one isn't bought at the cost of the other.

 Just wondering if mir or easier GPGPU programming could be that 
 killer application.

We sponsor mir algorithm (some of the routines within were 
developed for us, and we were happy to open source them), and we 
are rewriting our core analytics - used across the firm in a 
$4.1bn hedge fund in D from C++ before that.  What alternative 
really exists for what we are doing there?  And C++ vs D, it's 
not even a fair fight if you care about productivity, plasticity 
of the code, and generating wrappers for other languages that you 
can still understand whilst maintaining decent performance.  At 
the same time, we're not a D shop - a diversity of languages is 
not a bad thing, provided you have some way for them to work 
together.  Code reuse is very difficult, but the UNIX way does 
work.  On the other hand, if you want to connect components, how 
are you to do that?  Well, D is pretty nice for writing DSLs that 
can connect to code written in other languages, and where 
expressions can be evaluated from other languages.

A specialist language adapted to a particular domain or set of 
domains - yes, that benefits from a killer app.  But for a 
generalist language that's useful for getting stuff done - why 
would there be a single killer app?  That doesn't make sense to 
me.  There should be multiple successes across different domains, 
and that's what we are beginning to see.  Just bear in mind that 
the web and tech guys talk a lot, but most programmers don't work 
in those industries.  It would be a mistake to conflate salience 
with economic importance, I think.


Laeeth.

Russel Winder <russel winder.org.uk> writes:

On Sun, 2018-01-28 at 18:54 +0000, Laeeth Isharc via Digitalmars-d
wrote:
[=E2=80=A6]
 That's what you would expect, because D is a very ambitious=20
 language, which means its natural user base is much more spread=20
 out and less highly concentrated.  And beyond that, most code is=20
 enterprise code that's closed source, and whilst the web guys=20
 talk a lot and influence the culture, enterprise guys talk much=20
 less and just do their thing quietly.  Even in our world, how=20
 often do you see the people using D get involved in forum=20
 discussions?  Sociomantic, Weka, Ebay, and so on.  (Or Microsoft=20
 - did you know that D was used in their COM team?  They didn't=20
 exactly send out a press release...)  A little bit, but only a=20
 little in relation to their use of the language.  If you're=20
 trying to accomplish something in a representative enterprise=20
 context with lean resources, you don't have much time to talk=20
 about what you are doing.
=20
 If you want to draw people to the language (and, honestly, I=20
 wonder why it matters so much to many here - it's clearly taking=20
 hold, has momentum and will continue to grow for decades; an=20
 acorn will become an oak tree, and fretting about how much it's=20
 grown in the past year might be missing the point, so long as=20
 it's healthy enough), why not just focus on both improving the=20
 language itself (pull requests, documentation) and on=20
 accomplishing something useful and worth doing with it?

Go was ambitious, but grew more like a Cypress than an Oak. Many
reasons, we have mulled over this a number of time already. As I
remember the main ones:

0. Hype.
1. Timing.
2. Marketing.
3. Simple language that Google interns can use and not make errors.
4. Documentation.
5. Good standard library.
6. Ability to work with Git, Mercurial, and Bazaar repositories as
dependencies.
7. Documentation.
8. Funded support.
9. It replaces C. But then so does Rust.

Of course there were problems:

0. No way of doing complex repeatable builds.
1. The Web absorbs all.

There is a lot of proprietary as well as FOSS Go code. Ditto Java, C++.
But FOSS is where the marketing is and where many of the proprietary
decisions on programming language are made.

One thing that Go got almost right was the way of using FOSS packages
and libraries. Rust, via Cargo, did a much better job. Go has a small
standard library and allows use of any DVCS, there is no central
contributed system. Rust/Cargo has a small standard library, a central
contributed library, and the ability to use arbitrary DVCS. Rust/Cargo
wins on this hands down. I suggest Dub needs more work to be like
Cargo. This and documentation strike me as the most important things
for the evolution of D.

 Of course there are the usual trolls who don't seem to write much=20
 D, but seem to be drawn like vampires to the energy of those who=20
 do.  Sad.

:-)

 On Sunday, 28 January 2018 at 17:23:12 UTC, Paulo Pinto wrote:
 This has been mentioned multiple times, D really needs some=20
 kind of killer application.

=20
 Why?

s/killer// and you get a better measure. D needs more applications out
there to act as exemplars. Currently we have Tilix and=E2=80=A6

 It's a generalist language for getting stuff done in an age where=20
 people have succumbed so much to Stockholm Syndrome that they=20
 think it's a positive thing in a language that you can only use=20
 it to do something special.  Yet trends in performance and=20
 performance demands point to the rising importance of efficiency=20
 (and I suspect there will be a return to the recognition of the=20
 importance of being a generalist - in programming, as in other=20
 fields).  There was a tweet by the author of Musl libc observing=20
 that software today runs slower than software twenty years ago,=20
 and linking the bloat to the insane pressure to maximise CPU=20
 performance over all else.  The era of that kind of ruthless=20
 optimization is over because it's not the only thing that=20
 matters, and we start to see the price of it.  And generalism -=20
 in a dynamic business environment, there's considerable value to=20
 have capabilities that aren't adapted to particular narrow skills=20
 when what you need is always changing and may be unknown even to=20
 you.

I am less convinced by this argument. Go, Rust, and especially Java
have shown the power of tribalism and belonging to the one true tribe
eschewing all others. Java is a superb example of this: the JVM is now
a polyglot platform, and yet Java programmers, especially enterprise
ones, will only contemplate using Java and refuse to be educated about
Kotlin, Ceylon, Groovy, JRuby, etc. However when a feature inspired
(many years later) by the innovations in other JVM-based languages gets
shoehorned into Java then, eventually, the Java folk are prepared,
reluctantly, to learn about it. And maybe a few years later actually
use it.=20

 My generation was privileged because very quickly if you wanted=20
 to get anything interesting done you had to learn assembly=20
 language (maybe write your own assembler or disassembler), had to=20
 learn a bit about hardware, and could never pretend the CPU was=20
 this perfect platonic abstraction.  And for a while that changed,=20
 but I think the past is returning again, as it often does.

FORTRAN, the one true way. Who needs the intricacies of assembly
language when you have FORTRAN. :-)

 So I see a value in hiring hacker / generalist types who can=20
 figure things out.  For example:
=20

All companies should. Expertise in programming is not length of time on
one language, but the number of different computational models you can
work with to a reasonable quality of code.

Obviously familiarity with a set of needed API can be a help to speed
of getting a new person productive in a given project, but that is
learnable.


 Back in 2007, most finance types would have said how completely=20
 impracticable and unreasonable.  But I say, with GK Chesterton,=20
 that "all progress depends on the unreasonable man".  And someone=20
 like that doesn't succumb to helplessness once they are outside=20
 of their shiny IDE, knows that in the end everything is just=20
 code, and you can change it if you want to, and there is=20
 strategic value from building organisational capabilities from=20
 hiring such people.  Usually I'm a couple of years ahead, and I=20
 think others will follow.  If you hold a contrarian point of=20
 view, you know you're right when surprises start coming in your=20
 direction, and people still can't see it.  And I think that's=20
 been the case since 2014.
=20
 Anyway - so D is a general purpose language, and I think we are=20
 likely seeing a nascent return in recognizing the value of=20
 generalist tools and people.

It never really went away, we just had a period of PHP, JavaScript,
HTML, and CSS being all there was as far as people with money to fund
stuff were concerned.
=20
 On my line of work having Go on the skills list is slowly=20
 becoming a requirement, due to Docker and Kubernetes adoption=20
 on cloud infrastructures.

=20
 That's great.  Walter says that good code should look good on the=20
 page, and Go code looks nice enough.  It's got nice network and=20
 infra libraries, as you say.  But why would the adoption of Go be=20
 bad for D?  I think it's great for D because after a period of=20
 stagnation it gets people open to newer languages, and on the=20
 other hand the gap between the spirit of Go and D isn't that far=20
 (GC, clean code, native target) even if they don't have generics.=20
   It's a big world - both D and Go can succeed, and the success of=20
 one isn't bought at the cost of the other.

And Go has channels and task pools.=20

Whilst David Simcha did a lot of work on tasks and task pools for
std.parallelism, it only really addresses data parallelism. I think
there needs to be some work within std.concurrency and std.parallelism
to have a single task structure and "thread pool" system. That Go had
this from the outset is a Good Thing=E2=84=A2. Go does this at the language
level. D does it at the standard library level. Rust has gone one
further and has a low-level thread and channel system in the language
and standard library, everything else is in a separate library. This
raises the question of whether Phobos should be broken up.

Python originally had the "batteries included" view of it's standard
library, and continues to suffer problem because of trying to retain
this. PyPI and pip have removed the need for much of the standard
library. I am beginning to think that D needs a smaller standard
library (Phobos) and a better package system (Dub) taking lessons from
Rust and Cargo.

 Just wondering if mir or easier GPGPU programming could be that=20
 killer application.

=20
 We sponsor mir algorithm (some of the routines within were=20
 developed for us, and we were happy to open source them), and we=20
 are rewriting our core analytics - used across the firm in a=20
 $4.1bn hedge fund in D from C++ before that.  What alternative=20
 really exists for what we are doing there?  And C++ vs D, it's=20
 not even a fair fight if you care about productivity, plasticity=20
 of the code, and generating wrappers for other languages that you=20
 can still understand whilst maintaining decent performance.  At=20
 the same time, we're not a D shop - a diversity of languages is=20
 not a bad thing, provided you have some way for them to work=20
 together.  Code reuse is very difficult, but the UNIX way does=20
 work.  On the other hand, if you want to connect components, how=20
 are you to do that?  Well, D is pretty nice for writing DSLs that=20
 can connect to code written in other languages, and where=20
 expressions can be evaluated from other languages.
=20
 A specialist language adapted to a particular domain or set of=20
 domains - yes, that benefits from a killer app.  But for a=20
 generalist language that's useful for getting stuff done - why=20
 would there be a single killer app?  That doesn't make sense to=20
 me.  There should be multiple successes across different domains,=20
 and that's what we are beginning to see.  Just bear in mind that=20
 the web and tech guys talk a lot, but most programmers don't work=20
 in those industries.  It would be a mistake to conflate salience=20
 with economic importance, I think.

I agree we do not need "a killer app", but we do "exemplar apps", Tilix
is one, but more are needed. Also better documentation. I still find
the documentation for Phobos impenetrable most of the time. And the
documentation for GtkD and GStreamerD tells us about the C API not the
D binding. It clearly needs effort over and above what is being
provided, and there is no resource, so in all likelihood nothing will
change.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

Mafi <mafi example.org> writes:

On Monday, 29 January 2018 at 11:48:07 UTC, Russel Winder wrote:
 [...]
 One thing that Go got almost right was the way of using FOSS 
 packages and libraries. Rust, via Cargo, did a much better job. 
 Go has a small standard library and allows use of any DVCS, 
 there is no central contributed system. Rust/Cargo has a small 
 standard library, a central contributed library, and the 
 ability to use arbitrary DVCS. Rust/Cargo wins on this hands 
 down. I suggest Dub needs more work to be like Cargo. This and 
 documentation strike me as the most important things for the 
 evolution of D.
 [...]

What would you say are the most important differences between dub 
and Cargo? What does Cargo do better than dub (or worse for that 
matter)? Superficially, they seem to be designed quite similarly.

Mafi

Russel Winder <russel winder.org.uk> writes:

On Mon, 2018-01-29 at 17:18 +0000, Mafi via Digitalmars-d wrote:
=20

[=E2=80=A6]
 What would you say are the most important differences between dub=20
 and Cargo? What does Cargo do better than dub (or worse for that=20
 matter)? Superficially, they seem to be designed quite similarly.

The single most important thing is that Cargo stores source on a per
person basis and compiles for each project separately. Dub stores
source and compilation products on a per person basis. So, for me, Dub
does the wrong thing with compilation of dependencies, and Cargo does
it right. Why? Compiler choice and compiler option choice is a per
project thing, not a centralised thing.

Cargo allows for download from the central repository and from any
arbitrary Git or Mercurial repository. Dub only seems to get from the
central repository.

The Cargo repository is just nicer than the Dub repository.

Cargo uses TOML project specifications, Dub uses JSON or SDL. Cargo
wins, Dub doesn't.

The Cargo per project compilation product structure is nicer that Dubs.

It is certainly true that Dub and Cargo have the same aims and goal,
it's just that Cargo does it better on essentially all fronts as far as
the project build and builder are concerned.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

rjframe <dlang ryanjframe.com> writes:

On Tue, 30 Jan 2018 10:38:31 +0000, Russel Winder wrote:

 On Mon, 2018-01-29 at 17:18 +0000, Mafi via Digitalmars-d wrote:
 

 […]
 What would you say are the most important differences between dub and
 Cargo? What does Cargo do better than dub (or worse for that matter)?
 Superficially, they seem to be designed quite similarly.

 
 The single most important thing is that Cargo stores source on a per
 person basis and compiles for each project separately. Dub stores source
 and compilation products on a per person basis. So, for me, Dub does the
 wrong thing with compilation of dependencies, and Cargo does it right.
 Why? Compiler choice and compiler option choice is a per project thing,
 not a centralised thing.

Are you sure? Every project on my PC places the build files in
$PROJECTDIR/.dub/build; the source is in ~/.dub/packages.

That said, the name of the compiler is kept in the directory structure (as 
well as architecture and OS), which means there could be advantages to 
placing build artifacts globally, since compiler changes would still be 
separated, we get a reduction in disk usage and (sometimes) compile speed 
for already-built libraries.


 Cargo allows for download from the central repository and from any
 arbitrary Git or Mercurial repository. Dub only seems to get from the
 central repository.

This would be nice. I wonder though if the community is too small for this 
right now; remove the necessity of the central repository and it may die 
(I would say it's somewhat struggling as it is) -- and when it comes to 
finding libraries there are advantages to it that Github doesn't have.


 The Cargo repository is just nicer than the Dub repository.

It looks a lot nicer. I'm going to argue that as far as functionality 
though, it's horrible (note this is my first time looking in a long time):

- Home page is nice; it makes me want to use it.
- I click "Browse All Crates"; the default sort is alphabetical - not
  useful unless I'm just browsing, even then I'd likely want to browse by
  category. Each project takes up too much space (it looks like something's
  missing on each project), but I like the links to the project's
  homepage/repo/docs being right there in the list.
- I don't see any sort of categories/tags to organize projects. I guess I 
  have to know what I'm looking for and use the right search term.
- Overall, I have the impression that it was designed to look good, but
  less effort has gone into what people will want to do with it in the
  first place (assuming I can consider myself normal for a moment).

Dub doesn't look so nice, but it's efficient; I could see me searching 
Cargo for something and not finding it; I've never thought that about Dub 
(granted, far fewer packages) or Pypi.


 Cargo uses TOML project specifications, Dub uses JSON or SDL. Cargo
 wins, Dub doesn't.

Agreed.


 It is certainly true that Dub and Cargo have the same aims and goal,
 it's just that Cargo does it better on essentially all fronts as far as
 the project build and builder are concerned.

Have you opened issues on the dub repository for the various problems you 
see?

--Ryan

Benny <benny.luypaert rhysoft.com> writes:

On Tuesday, 30 January 2018 at 11:55:42 UTC, rjframe wrote:
 - I click "Browse All Crates"; the default sort is alphabetical 
 - not
   useful unless I'm just browsing,

Right side:

* Alphabetical
* All-Time Downloads
* Recent Downloads

 even then I'd likely want to browse by category.

https://crates.io/categories

 Each project takes up too much space (it looks like something's
   missing on each project), but I like the links to the 
 project's
   homepage/repo/docs being right there in the list.
 - I don't see any sort of categories/tags to organize projects.

https://crates.io/categories

 I guess I
   have to know what I'm looking for and use the right search 
 term.
 - Overall, I have the impression that it was designed to look 
 good, but
   less effort has gone into what people will want to do with it 
 in the
   first place (assuming I can consider myself normal for a 
 moment).

 Dub doesn't look so nice, but it's efficient; I could see me 
 searching Cargo for something and not finding it;

True... but both dub and cargo are not exactly the pinnacle in 
user friendly and informative packages websites.

 I've never thought that about Dub (granted, far fewer packages) 
 or Pypi.

  1,193 packages found
13,605 Crates in stock Side note: End of 2016, this was 1400.

If you consider 12 times "far fewer packages".

The issue is that a lot of D's packages are even less maintained 
then Rust, mostly because Rust being newer and attracting more 
active crowds. And it does not help when Dmd having constant 
deprecating functions and regressions ( what happens WAY too 
often ) that break packages.

Its a long term weakness. Depending on 3th party packages is 
always dangerous but even more so when the compiler forces people 
to use older versions, just to stay safe.

rjframe <dlang ryanjframe.com> writes:

On Wed, 31 Jan 2018 00:34:48 +0000, Benny wrote:

 https://crates.io/categories

Thanks. I wish that was easier to find though. I still don't see how to 
get there without knowing it already exists.


 The issue is that a lot of D's packages are even less maintained then
 Rust, mostly because Rust being newer and attracting more active crowds.
 And it does not help when Dmd having constant deprecating functions and
 regressions ( what happens WAY too often ) that break packages.
 
 Its a long term weakness. Depending on 3th party packages is always
 dangerous but even more so when the compiler forces people to use older
 versions, just to stay safe.

Yeah, I'm not sure how cruft should be handled; maybe move anything that 
hasn't had a single commit in 4 years to an Archive category which is 
hidden by default... at the rate D changes, even the simplest libraries 
that haven't been touched in four years likely have a deprecation or error 
to handle (or documentation that could be improved), and if the registry 
could create an issue as a warning first, nobody should be surprised by 
their project being archived.

I wonder if the Dub registry could read a CI configuration file to grab 
the tested D compilers in a repo, and display them on the package's page 
as supported compilers. I don't know if people would interpret that to 
imply that the package is incompatible with anything not listed though.

Russel Winder <russel winder.org.uk> writes:

On Tue, 2018-01-30 at 11:55 +0000, rjframe via Digitalmars-d wrote:
 On Tue, 30 Jan 2018 10:38:31 +0000, Russel Winder wrote:
=20

[=E2=80=A6]
=20
 Are you sure? Every project on my PC places the build files in
 $PROJECTDIR/.dub/build; the source is in ~/.dub/packages.

I see the source of the dependencies both in ~/.dub/packages and in the
project .dub directory, but I see the compilation products in
~/.dub/packages. There are every compiled version in obscure named sub-
directories and the last compiled (unknown compiler and options) in the
dependency directory.

Compilation seems to be only of .a and not (.so|.dll).

 That said, the name of the compiler is kept in the directory
 structure (as=20
 well as architecture and OS), which means there could be advantages
 to=20
 placing build artifacts globally, since compiler changes would still
 be=20
 separated, we get a reduction in disk usage and (sometimes) compile
 speed=20
 for already-built libraries.

In which case, why is there anything in the project directory at all.

Also the OS/compiler/options is all encoded in a very long and obscure
naming directory name, rather than a nice directory hierarchy. Chapel
made this switch and it improved everything a lot.=20

[=E2=80=A6]
 This would be nice. I wonder though if the community is too small for
 this=20
 right now; remove the necessity of the central repository and it may
 die=20
 (I would say it's somewhat struggling as it is) -- and when it comes
 to=20
 finding libraries there are advantages to it that Github doesn't
 have.

I think not. The Rust experience is that the mixed economy of central
released and actively curated (though Rust hasn't quite got to that yet
sadly, there is a build up of crap just as happens with PyPI) and use
of Git repository HEADs works very well. The Go experience of not
having a central place, just the Git/Mercurial/Bazaar/Breezy
repositories leads to a lot of hassle, and thence to vendoring. Ceylon
as well as D only has the central repository and it can be very
annoying.

Having the central repo is a good thing, but having access to DVCS is
as well.

=20
 The Cargo repository is just nicer than the Dub repository.

=20
=20
 [=E2=80=A6]

Clearly there is debate to be had about the Cargo vs. Dub repositories,
I agree and disagree with the points you made, but that is for the Dub
forum I guess.=20

(I hate forums without email support, but I guess I could look at the
Dub forum from time to time.)

=20
 Cargo uses TOML project specifications, Dub uses JSON or SDL. Cargo
 wins, Dub doesn't.

=20
 Agreed.

Sadly I suspect there is no future in this point, the JSON/SDL fight
seems to have used up everyone's energy and moving to an actually good
format is not on the cards.
=20
 [=E2=80=A6]
 Have you opened issues on the dub repository for the various problems
 you=20
 see?

Not as yet, but I guess I will have to overcome my abhorrence of
forums, and post to the Dub forum.

(Did I mention I really hate forums with no email interface. Probably.)

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

Jacob Carlborg <doob me.com> writes:

On 2018-02-01 13:19, Russel Winder wrote:

 I see the source of the dependencies both in ~/.dub/packages and in the
 project .dub directory, but I see the compilation products in
 ~/.dub/packages. 

I'm wondering if this might be different versions of Dub behaving 
differently. I have 79 packages in ~/.dub/packages and only three object 
files in two different projects.

$ ls -l ~/.dub/packages | wc -l
       79

$ cd ~/.dub/packages && find . -name '*.o'
./dfmt-0.4.4/.dub/build/application-debug-posix.osx-x86_64-dmd_2069-EEECF44B144F658EA70D0E82862DE408/dfmt.o
./dfmt-0.4.4/.dub/build/application-debug-posix.osx-x86_64-dmd_2070-5AD8691A40E4B0418752E48F1E27075F/dfmt.o
./unit-threaded-0.7.15/unit-threaded/.dub/build/gen_ut_main-debug-posix.osx-x86_64-dmd_2072-5674F70F27B1DC65A685FF95F866B7F7/gen_ut_main.o

 There are every compiled version in obscure named sub-
 directories and the last compiled (unknown compiler and options) in the
 dependency directory.

It's just a cache, it's not something that the user need to look at.

-- 
/Jacob Carlborg

Atila Neves <atila.neves gmail.com> writes:

On Thursday, 1 February 2018 at 12:19:48 UTC, Russel Winder wrote:
 On Tue, 2018-01-30 at 11:55 +0000, rjframe via Digitalmars-d 
 wrote:
 On Tue, 30 Jan 2018 10:38:31 +0000, Russel Winder wrote:
 

 […]
 
 Are you sure? Every project on my PC places the build files in 
 $PROJECTDIR/.dub/build; the source is in ~/.dub/packages.

 I see the source of the dependencies both in ~/.dub/packages 
 and in the project .dub directory, but I see the compilation 
 products in ~/.dub/packages. There are every compiled version 
 in obscure named sub- directories and the last compiled 
 (unknown compiler and options) in the dependency directory.

 Compilation seems to be only of .a and not (.so|.dll).

Whether it's .a or .so depends on the dependent package being 
`staticLibrary` or `dynamicLibrary`. It's possible for a package 
to be both if it has a configuration for each.

Personally I don't even see the point - just link all the .o 
files. In a traditional build system static libraries might be 
useful to specify that multiple targets link to this particular 
binary blob. With dub there's only ever one binary anyway.

And at this point in time I think shared libraries are mostly a 
mistake. The only time I use them is when I have to, as in when 
developing Python extensions.

Atila

Russel Winder <russel winder.org.uk> writes:

On Fri, 2018-02-02 at 10:03 +0000, Atila Neves via Digitalmars-d wrote:
=20

[=E2=80=A6]
 Whether it's .a or .so depends on the dependent package being=20
 `staticLibrary` or `dynamicLibrary`. It's possible for a package=20
 to be both if it has a configuration for each.

I think that is one of my points, the package source downloaded from
the Dub repository should not be determining whether a .a or ,so is
produced, it should be determined by the receiver of the downloaded
package.

 Personally I don't even see the point - just link all the .o=20
 files. In a traditional build system static libraries might be=20
 useful to specify that multiple targets link to this particular=20
 binary blob. With dub there's only ever one binary anyway.

But a static library is just a collection of .o files so I think it
fits with "link all the .o together".

It is clear that there is a move in the Go, Rust, D communities to
rejecting the concept of shared library, and that 100MB executables are
acceptable.

 And at this point in time I think shared libraries are mostly a=20
 mistake. The only time I use them is when I have to, as in when=20
 developing Python extensions.

The single biggest argument for shared libraries in D is GtkD. Linking
an executable with a static GtkD library takes ages, and when
developing you do a lot of linking. Fast turnaround, and thus
reasonable development times, requires use of a shared library for
GtkD.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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

Atila Neves <atila.neves gmail.com> writes:

On Friday, 2 February 2018 at 14:04:09 UTC, Russel Winder wrote:
 On Fri, 2018-02-02 at 10:03 +0000, Atila Neves via 
 Digitalmars-d wrote:
 

 […]
 Whether it's .a or .so depends on the dependent package being 
 `staticLibrary` or `dynamicLibrary`. It's possible for a 
 package to be both if it has a configuration for each.

 I think that is one of my points, the package source downloaded 
 from the Dub repository should not be determining whether a .a 
 or ,so is produced, it should be determined by the receiver of 
 the downloaded package.

 Personally I don't even see the point - just link all the .o 
 files. In a traditional build system static libraries might be 
 useful to specify that multiple targets link to this 
 particular binary blob. With dub there's only ever one binary 
 anyway.

 But a static library is just a collection of .o files so I 
 think it fits with "link all the .o together".

Not quite. There's an extra step and when linking with a static 
library unused symbols are thrown away by default. That hid a dmd 
bug in 2.078.0 that only manifests when linking with the object 
files themselves.

 It is clear that there is a move in the Go, Rust, D communities 
 to rejecting the concept of shared library, and that 100MB 
 executables are acceptable.

On a desktop, 100MB executables are, at least to me. Shared 
libraries aren't going to magically make 100MB executables 
disappear, it depends on how much code is actually shared.

 And at this point in time I think shared libraries are mostly 
 a mistake. The only time I use them is when I have to, as in 
 when developing Python extensions.

 The single biggest argument for shared libraries in D is GtkD. 
 Linking an executable with a static GtkD library takes ages, 
 and when developing you do a lot of linking. Fast turnaround, 
 and thus reasonable development times, requires use of a shared 
 library for GtkD.

That's a fair point.

Atila

Joakim <dlang joakim.fea.st> writes:

On Monday, 29 January 2018 at 11:48:07 UTC, Russel Winder wrote:
 I am less convinced by this argument. Go, Rust, and especially 
 Java have shown the power of tribalism and belonging to the one 
 true tribe eschewing all others. Java is a superb example of 
 this: the JVM is now a polyglot platform, and yet Java 
 programmers, especially enterprise ones, will only contemplate 
 using Java and refuse to be educated about Kotlin, Ceylon, 
 Groovy, JRuby, etc. However when a feature inspired (many years 
 later) by the innovations in other JVM-based languages gets 
 shoehorned into Java then, eventually, the Java folk are 
 prepared, reluctantly, to learn about it. And maybe a few years 
 later actually use it.

I thought this was a killer anecdote about maybe the first 
programming language war... over assembly language:

"Margaret Hamilton, a celebrated software engineer on the Apollo 
missions—in fact the coiner of the phrase 'software 
engineering'—told me that during her first year at the Draper lab 
at MIT, in 1964, she remembers a meeting where one faction was 
fighting the other about transitioning away from 'some very low 
machine language,' as close to ones and zeros as you could get, 
to 'assembly language.' 'The people at the lowest level were 
fighting to keep it. And the arguments were so similar: ‘Well how 
do we know assembly language is going to do it right?’'

'Guys on one side, their faces got red, and they started 
screaming,' she said. She said she was 'amazed how emotional they 
got.'

Emmanuel Ledinot, of Dassault Aviation, pointed out that when 
assembly language was itself phased out in favor of the 
programming languages still popular today, like C, it was the 
assembly programmers who were skeptical this time."
https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/

Good to see things haven't changed in a half-century. ;) Not that 
I'm saying assembly was the obvious choice: maybe their 
assemblers were buggy or slow or whatever, it all depends on the 
details.

aberba <karabutaworld gmail.com> writes:

On Sunday, 28 January 2018 at 18:54:34 UTC, Laeeth Isharc wrote:
 On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
 I do worry that, having been using D for about 3 1/2 years 
 now, that the perceptions of D outside of this community don't 
 seem to be changing much. It does seem to make a huge 
 difference to have a big company behind a language, purely for 
 the "free advertisement". Most people at my university, 
 outside of the computer science department, that are using 
 languages like Python and R and MATLAB the most, are very 
 aware of Rust and Go, but not D. I wonder if we do need to pay 
 more attention to attracting new users just to get people 
 talking about it.

 That's what you would expect, because D is a very ambitious 
 language, which means its natural user base is much more spread 
 out and less highly concentrated.  And beyond that, most code 
 is enterprise code that's closed source, and whilst the web 
 guys talk a lot and influence the culture, enterprise guys talk 
 much less and just do their thing quietly.  Even in our world, 
 how often do you see the people using D get involved in forum 
 discussions?  Sociomantic, Weka, Ebay, and so on.  (Or 
 Microsoft - did you know that D was used in their COM team?  
 They didn't exactly send out a press release...)  A little bit, 
 but only a little in relation to their use of the language.  If 
 you're trying to accomplish something in a representative 
 enterprise context with lean resources, you don't have much 
 time to talk about what you are doing.

That's one big potential mistake. Enterprises care about making 
money with whatever will help them do that (impress investors). 
Its developers who care about languages that help them write code 
that suites their requirements. The focus should be on developers 
not companies. People using D cannot be represented by Microsoft, 
  Sociomantic,  Weka,  etc. employees. Its of no use chasing after 
companies... make it useful and everyone else will come.


 If you want to draw people to the language (and, honestly, I 
 wonder why it matters so much to many here

Its a simple math well understood since long ago.  The larger the 
army/workforce the better. Things get done. Walter always say 
here "Its left with someone to do the work". There other stuff he 
doesn't address including those outside language internals.

- it's clearly
 taking hold, has momentum and will continue to grow for 
 decades; an acorn will become an oak tree, and fretting about 
 how much it's grown in the past year might be missing the 
 point, so long as it's healthy enough), why not just focus on 
 both improving the language itself (pull requests, 
 documentation)

Someone needs to do that and we're short of people willing,  have 
the time and able to do that.

Either someone is paid to care enough to do that (Like Google do 
with Go, Oracle with Java,  Jetbrains with Kotlin,  etc.) OR grow 
a community/workforce to collectively make that happen.

 and on accomplishing something useful and worth doing with it?

There's also a possibility the acorn will loose interest and 
momentum and... die. Your opinion on what is worth doing is based 
on your domain or interest.

 Of course there are the usual trolls who don't seem to write 
 much D, but seem to be drawn like vampires to the energy of 
 those who do.  Sad.

Someone who doesn't write D or have no stake in it's well-being 
will not waste a second in this forum.

 don't seem

You don't know for sure. Remember we don't all use D the same way.

 On Sunday, 28 January 2018 at 17:23:12 UTC, Paulo Pinto wrote:
 This has been mentioned multiple times, D really needs some 
 kind of killer application.

 Why?

 It's a generalist language for getting stuff done in an age 
 where people have succumbed so much to Stockholm Syndrome that 
 they think it's a positive thing in a language that you can 
 only use it to do something special.  Yet trends in performance 
 and performance demands point to the rising importance of 
 efficiency (and I suspect there will be a return to the 
 recognition of the importance of being a generalist - in 
 programming, as in other fields).  There was a tweet by the 
 author of Musl libc observing that software today runs slower 
 than software twenty years ago, and linking the bloat to the 
 insane pressure to maximise CPU performance over all else.  The 
 era of that kind of ruthless optimization is over because it's 
 not the only thing that matters, and we start to see the price 
 of it.  And generalism - in a dynamic business environment, 
 there's considerable value to have capabilities that aren't 
 adapted to particular narrow skills when what you need is 
 always changing and may be unknown even to you.

 My generation was privileged because very quickly if you wanted 
 to get anything interesting done you had to learn assembly 
 language (maybe write your own assembler or disassembler), had 
 to learn a bit about hardware, and could never pretend the CPU 
 was this perfect platonic abstraction.  And for a while that 
 changed, but I think the past is returning again, as it often 
 does.

 So I see a value in hiring hacker / generalist types who can 
 figure things out.  For example:

 https://hackaday.com/2017/01/26/a-personal-fight-against-the-modern-laptop/
 https://www.youtube.com/watch?v=Fzmm87oVQ6c

 Back in 2007, most finance types would have said how completely 
 impracticable and unreasonable.  But I say, with GK Chesterton, 
 that "all progress depends on the unreasonable man".  And 
 someone like that doesn't succumb to helplessness once they are 
 outside of their shiny IDE, knows that in the end everything is 
 just code, and you can change it if you want to, and there is 
 strategic value from building organisational capabilities from 
 hiring such people.  Usually I'm a couple of years ahead, and I 
 think others will follow.  If you hold a contrarian point of 
 view, you know you're right when surprises start coming in your 
 direction, and people still can't see it.  And I think that's 
 been the case since 2014.

 Anyway - so D is a general purpose language, and I think we are 
 likely seeing a nascent return in recognizing the value of 
 generalist tools and people.

 On my line of work having Go on the skills list is slowly 
 becoming a requirement, due to Docker and Kubernetes adoption 
 on cloud infrastructures.

 That's great.  Walter says that good code should look good on 
 the page, and Go code looks nice enough.  It's got nice network 
 and infra libraries, as you say.  But why would the adoption of 
 Go be bad for D?  I think it's great for D because after a 
 period of stagnation it gets people open to newer languages, 
 and on the other hand the gap between the spirit of Go and D 
 isn't that far (GC, clean code, native target) even if they 
 don't have generics.
  It's a big world - both D and Go can succeed, and the success 
 of one isn't bought at the cost of the other.

 Just wondering if mir or easier GPGPU programming could be 
 that killer application.

 We sponsor mir algorithm (some of the routines within were 
 developed for us, and we were happy to open source them), and 
 we are rewriting our core analytics - used across the firm in a 
 $4.1bn hedge fund in D from C++ before that.  What alternative 
 really exists for what we are doing there?  And C++ vs D, it's 
 not even a fair fight if you care about productivity, 
 plasticity of the code, and generating wrappers for other 
 languages that you can still understand whilst maintaining 
 decent performance.  At the same time, we're not a D shop - a 
 diversity of languages is not a bad thing, provided you have 
 some way for them to work together.  Code reuse is very 
 difficult, but the UNIX way does work.  On the other hand, if 
 you want to connect components, how are you to do that?  Well, 
 D is pretty nice for writing DSLs that can connect to code 
 written in other languages, and where expressions can be 
 evaluated from other languages.

 A specialist language adapted to a particular domain or set of 
 domains - yes, that benefits from a killer app.  But for a 
 generalist language that's useful for getting stuff done - why 
 would there be a single killer app?  That doesn't make sense to 
 me.  There should be multiple successes across different 
 domains, and that's what we are beginning to see.  Just bear in 
 mind that the web and tech guys talk a lot, but most 
 programmers don't work in those industries.  It would be a 
 mistake to conflate salience with economic importance, I think.


 Laeeth.

rjframe <dlang ryanjframe.com> writes:

On Tue, 30 Jan 2018 09:20:37 +0000, aberba wrote:

 That's one big potential mistake. Enterprises care about making money
 with whatever will help them do that (impress investors). Its developers
 who care about languages that help them write code that suites their
 requirements. The focus should be on developers not companies. People
 using D cannot be represented by Microsoft,
   Sociomantic,  Weka,  etc. employees. Its of no use chasing after
 companies... make it useful and everyone else will come.

Well... if the goal is merely number of programmers, getting enterprises 
on-board is the easiest way to do it. Many (most?) professional 
programmers write nothing/very little after hours. Even if the programmers 
are on board, getting management to sign off may require throwing big 
names around.

 
 If you want to draw people to the language (and, honestly, I wonder why
 it matters so much to many here

 Its a simple math well understood since long ago.  The larger the
 army/workforce the better. Things get done. Walter always say here "Its
 left with someone to do the work". There other stuff he doesn't address
 including those outside language internals.

Most people that use a language (whether D, Rust, Python, C++) use their 
for their own projects, rather than for development of the language itself 
(I don't know about anyone else, but that's why I was looking for a new 
language in the first place). Increasing the number of programmers may 
just increase the number of requests for better infrastructure.

Better tooling isn't going to come from numbers; more likely from 
something like:

- A hobbyist that wants to build something, either for enjoyment or some
  other desire.
- An organization investing in tools to increase the productivity of its
  programmers.
- A partnership with a CS department somewhere, which might be mutually
  beneficial as students gain real-world experience arguing with engineers
  and graduate with code that they've written being used in production.


 Either someone is paid to care enough to do that (Like Google do with
 Go, Oracle with Java,  Jetbrains with Kotlin,  etc.) OR grow a
 community/workforce to collectively make that happen.

Like they always say, "It takes money to spend money." :)


 Of course there are the usual trolls who don't seem to write much D,
 but seem to be drawn like vampires to the energy of those who do.  Sad.

 
 Someone who doesn't write D or have no stake in it's well-being will not
 waste a second in this forum.

People are people, the Internet's the Internet. Anything can happen.


 You don't know for sure. Remember we don't all use D the same way.

There's a DConf slogan for some year; it could highlight the diversity of 
uses/tasks/problems people solve with D.


--Ryan

John Gabriele <jgabriele fastmail.fm> writes:

On Tuesday, 30 January 2018 at 09:20:37 UTC, aberba wrote:
 On Sunday, 28 January 2018 at 18:54:34 UTC, Laeeth Isharc wrote:
 On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:

 Enterprises care about making money with whatever will help 
 them do that (impress investors). Its developers who care about 
 languages that help them write code that suites their 
 requirements. The focus should be on developers not companies. 
 People using D cannot be represented by Microsoft,
  Sociomantic,  Weka,  etc. employees. Its of no use chasing 
 after companies... make it useful and everyone else will come.

 If you want to draw people to the language (and, honestly, I 
 wonder why it matters so much to many here

 Its a simple math well understood since long ago.  The larger 
 the army/workforce the better. Things get done. Walter always 
 say here "Its left with someone to do the work". There other 
 stuff he doesn't address including those outside language 
 internals.

- it's clearly
 taking hold, has momentum and will continue to grow for 
 decades; an acorn will become an oak tree, and fretting about 
 how much it's grown in the past year might be missing the 
 point, so long as it's healthy enough), why not just focus on 
 both improving the language itself (pull requests, 
 documentation)

 Someone needs to do that and we're short of people willing,  
 have the time and able to do that.

 Either someone is paid to care enough to do that (Like Google 
 do with Go, Oracle with Java,  Jetbrains with Kotlin,  etc.) OR 
 grow a community/workforce to collectively make that happen.

 and on accomplishing something useful and worth doing with it?

 There's also a possibility the acorn will loose interest and 
 momentum and... die. Your opinion on what is worth doing is 
 based on your domain or interest.

I get the impression that a wave is coming (or is already here) 
where people more and more are looking for modern 
natively-compiled statically-typed languages --- leaving 
Python/Perl/Ruby/PHP/JS --- not only for performance, but for 
easier development for larger projects.

The languages I see benefiting primarily from this wave are D, 
Rust, Go, and Kotlin/Native.

Of those, my impression is that Rust and Kotlin are perceived as 
the most modern. Go and Rust have some hype, but Go's hype seems 
to have already peaked. D appears well-positioned (good 
community, high-level with GC, has dub and <code.dlang.org>, docs 
and books are available).

If there are areas of D that need to be modernized, streamlined, 
or simplified, but which will break backcompat, now may be a 
excellent time to consider beginning those changes/deprecations.

Laeeth Isharc <Laeeth kaleidic.io> writes:

On Tuesday, 30 January 2018 at 09:20:37 UTC, aberba wrote:
 On Sunday, 28 January 2018 at 18:54:34 UTC, Laeeth Isharc wrote:
 On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
 I do worry that, having been using D for about 3 1/2 years 
 now, that the perceptions of D outside of this community 
 don't seem to be changing much. It does seem to make a huge 
 difference to have a big company behind a language, purely 
 for the "free advertisement". Most people at my university, 
 outside of the computer science department, that are using 
 languages like Python and R and MATLAB the most, are very 
 aware of Rust and Go, but not D. I wonder if we do need to 
 pay more attention to attracting new users just to get people 
 talking about it.

 That's what you would expect, because D is a very ambitious 
 language, which means its natural user base is much more 
 spread out and less highly concentrated.  And beyond that, 
 most code is enterprise code that's closed source, and whilst 
 the web guys talk a lot and influence the culture, enterprise 
 guys talk much less and just do their thing quietly.  Even in 
 our world, how often do you see the people using D get 
 involved in forum discussions?  Sociomantic, Weka, Ebay, and 
 so on.  (Or Microsoft - did you know that D was used in their 
 COM team?  They didn't exactly send out a press release...)  A 
 little bit, but only a little in relation to their use of the 
 language.  If you're trying to accomplish something in a 
 representative enterprise context with lean resources, you 
 don't have much time to talk about what you are doing.

 That's one big potential mistake. Enterprises care about making 
 money with whatever will help them do that (impress investors). 
 Its developers who care about languages that help them write 
 code that suites their requirements. The focus should be on 
 developers not companies. People using D cannot be represented 
 by Microsoft,
  Sociomantic,  Weka,  etc. employees. Its of no use chasing 
 after companies... make it useful and everyone else will come.

Who said anything about chasing after companies? There's not much 
chasing after anyone, companies or developers.  One reason the 
quality of people here is so high.  We have a filter that 
fortuitously selects for people with good taste and who don't 
care about superficial things as much.  Learning costs and 
discomfort are amortised, and from an expected value perspective 
are trivial from a long run perspective.  And I suggest it's 
almost a negative cost because one is forced to learn things that 
are good to learn.  I speak very personally when I say this, 
because the value to me of what I have learnt is beyond 
calculation, and let's say that it is a very big number by the 
standards of the industry.

And I don't accept the distinction between developers and 
companies particularly for small and medium sized companies.  
Liran at Weka, I'd call him a pretty serious developer, no? But 
he is also a co-founder and leader of his company.  The 
Sociomantic guys - that goes without saying.  Bastiaan same 
story.  I don't know what role the technical leadership of 
Funkwerk play in running the company, but that was I think a 
decision adopted at a senior level - they have been using D for a 
decade and their product is everywhere.  The train you took 
doesn't say timetable powered by D, but maybe in some years it 
will, haha.  An interesting looking stock chart by the way.  EMSI 
- founder developers adopted D.  Personally I'm in charge of tech 
for a 95 person company and involved in other areas of management 
beyond tech and I'm also a developer.

Every language is based on different principles.  The way D will 
be adopted is via people who are principals giving it a try 
because it solves their problems.  There is no point trying to 
spend much time appealing to those in management who can't make 
decisions themselves and need to consider social factors because 
we have a much better product than we do marketing.  That's okay, 
the social appeal will come later and in truth when it does it 
will be a mixed blessing because the quality of the community 
will change.

 If you want to draw people to the language (and, honestly, I 
 wonder why it matters so much to many here

 Its a simple math well understood since long ago.  The larger 
 the army/workforce the better. Things get done. Walter always 
 say here "Its left with someone to do the work". There other 
 stuff he doesn't address including those outside language 
 internals.

Sure, but you are I think mistaking ends for means.  Things 
develop at their own pace and I don't think can be forced.  I've 
noticed that changes tend to happen when they are good and ready 
and not when we wish they would.  So in that context it makes 
sense to focus on what you can control and influence and not on 
what one wishes might be the case.  If wishes were horses beggars 
would ride.  But they don't...

So that doesn't mean that one shouldn't work on guerilla 
marketing if that's what one wishes to do.  But expecting Walter 
or Andrei to come up with a grand plan when there isn't the basis 
for it yet doesn't advance things much.

What one can do is take action, and the smallest actions can have 
very powerful effects because they inspire others.

Seb Wilzbach has been a master of this.  Taking just one small 
example : nobody told him to do anything.  But he thought D 
should have runnable examples.  He wrote code to transform unit 
tests into examples and made them runnable.  (Maybe others were 
involved, I didn't follow).  And I think that small action has 
had more impact on the prospects for D than all the talk without 
action that others have spent time on since he became involved in 
the community.
- it's clearly
 taking hold, has momentum and will continue to grow for 
 decades; an acorn will become an oak tree, and fretting about 
 how much it's grown in the past year might be missing the 
 point, so long as it's healthy enough), why not just focus on 
 both improving the language itself (pull requests, 
 documentation)

 Someone needs to do that and we're short of people willing,  
 have the time and able to do that.

Human creativity is unlimited.  We will always be short of 
resources. However scarcity is also the mother of invention.  The 
time spent wishing for improvements could also be spent reviewing 
or writing pull requests blog posts, documentation improvements 
etc.  (I know you have written some blog posts).

 Either someone is paid to care enough to do that (Like Google 
 do with Go, Oracle with Java,  Jetbrains with Kotlin,  etc.) OR 
 grow a community/workforce to collectively make that happen.

Compare the documentation today with early 2014.  And the books 
available.  It's massively improved and in outright terms not bad.

What I'm suggesting is that things will continue to get better 
with the passage of time.  Also because external conditions keep 
moving in directions favourable to D.  The calculus of the pace 
of data set sizes to cpu and especially RAM performance is 
inexorable.  And BTW Spectre and Meltdown, they aren't at the 
margin going to get CPU manufacturers to say you know we really 
need to accelerate performance from here - on the contrary, there 
might need to be a change in focus, and everything is a tradeoff.

When conditions shift the people that adopt strategies adapted to 
new conditions mysteriously seem to start doing well.  And people 
copy what's working.  So another factor is that people who start 
using D, it often seems to be quite good for their careers.  From 
the people I have known anyway over the course of a few years.

 and on accomplishing something useful and worth doing with it?

 There's also a possibility the acorn will loose interest and 
 momentum and... die. Your opinion on what is worth doing is 
 based on your domain or interest.

Life is risk, and anything is possible.  Maybe we shall be 
obliterated by a stray asteroid.  Both scenarios are possible, 
but I don't think so.  Things are growing, and external 
conditions are favourable. What I do involves recognising 
patterns in social things (like language communities), and I've 
seen this before.  D is going to keep growing, and to my eyes is 
already flourishing. Expect plenty of setbacks along the way, for 
that is life, but it's the setbacks that build strength.


 Of course there are the usual trolls who don't seem to write 
 much D, but seem to be drawn like vampires to the energy of 
 those who do.  Sad.

 Someone who doesn't write D or have no stake in it's well-being 
 will not waste a second in this forum.

People are strange creatures,some more than others.
 don't seem

 You don't know for sure. Remember we don't all use D the same 
 way.

 On Sunday, 28 January 2018 at 17:23:12 UTC, Paulo Pinto wrote:
 This has been mentioned multiple times, D really needs some 
 kind of killer application.

 Why?

 It's a generalist language for getting stuff done in an age 
 where people have succumbed so much to Stockholm Syndrome that 
 they think it's a positive thing in a language that you can 
 only use it to do something special.  Yet trends in 
 performance and performance demands point to the rising 
 importance of efficiency (and I suspect there will be a return 
 to the recognition of the importance of being a generalist - 
 in programming, as in other fields).  There was a tweet by the 
 author of Musl libc observing that software today runs slower 
 than software twenty years ago, and linking the bloat to the 
 insane pressure to maximise CPU performance over all else.  
 The era of that kind of ruthless optimization is over because 
 it's not the only thing that matters, and we start to see the 
 price of it.  And generalism - in a dynamic business 
 environment, there's considerable value to have capabilities 
 that aren't adapted to particular narrow skills when what you 
 need is always changing and may be unknown even to you.

 My generation was privileged because very quickly if you 
 wanted to get anything interesting done you had to learn 
 assembly language (maybe write your own assembler or 
 disassembler), had to learn a bit about hardware, and could 
 never pretend the CPU was this perfect platonic abstraction.  
 And for a while that changed, but I think the past is 
 returning again, as it often does.

 So I see a value in hiring hacker / generalist types who can 
 figure things out.  For example:

 https://hackaday.com/2017/01/26/a-personal-fight-against-the-modern-laptop/
 https://www.youtube.com/watch?v=Fzmm87oVQ6c

 Back in 2007, most finance types would have said how 
 completely impracticable and unreasonable.  But I say, with GK 
 Chesterton, that "all progress depends on the unreasonable 
 man".  And someone like that doesn't succumb to helplessness 
 once they are outside of their shiny IDE, knows that in the 
 end everything is just code, and you can change it if you want 
 to, and there is strategic value from building organisational 
 capabilities from hiring such people.  Usually I'm a couple of 
 years ahead, and I think others will follow.  If you hold a 
 contrarian point of view, you know you're right when surprises 
 start coming in your direction, and people still can't see it.
  And I think that's been the case since 2014.

 Anyway - so D is a general purpose language, and I think we 
 are likely seeing a nascent return in recognizing the value of 
 generalist tools and people.

 On my line of work having Go on the skills list is slowly 
 becoming a requirement, due to Docker and Kubernetes adoption 
 on cloud infrastructures.

 That's great.  Walter says that good code should look good on 
 the page, and Go code looks nice enough.  It's got nice 
 network and infra libraries, as you say.  But why would the 
 adoption of Go be bad for D?  I think it's great for D because 
 after a period of stagnation it gets people open to newer 
 languages, and on the other hand the gap between the spirit of 
 Go and D isn't that far (GC, clean code, native target) even 
 if they don't have generics.
  It's a big world - both D and Go can succeed, and the success 
 of one isn't bought at the cost of the other.

 Just wondering if mir or easier GPGPU programming could be 
 that killer application.

 We sponsor mir algorithm (some of the routines within were 
 developed for us, and we were happy to open source them), and 
 we are rewriting our core analytics - used across the firm in 
 a $4.1bn hedge fund in D from C++ before that.  What 
 alternative really exists for what we are doing there?  And 
 C++ vs D, it's not even a fair fight if you care about 
 productivity, plasticity of the code, and generating wrappers 
 for other languages that you can still understand whilst 
 maintaining decent performance.  At the same time, we're not a 
 D shop - a diversity of languages is not a bad thing, provided 
 you have some way for them to work together.  Code reuse is 
 very difficult, but the UNIX way does work.  On the other 
 hand, if you want to connect components, how are you to do 
 that?  Well, D is pretty nice for writing DSLs that can 
 connect to code written in other languages, and where 
 expressions can be evaluated from other languages.

 A specialist language adapted to a particular domain or set of 
 domains - yes, that benefits from a killer app.  But for a 
 generalist language that's useful for getting stuff done - why 
 would there be a single killer app?  That doesn't make sense 
 to me.  There should be multiple successes across different 
 domains, and that's what we are beginning to see.  Just bear 
 in mind that the web and tech guys talk a lot, but most 
 programmers don't work in those industries.  It would be a 
 mistake to conflate salience with economic importance, I think.


 Laeeth.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Tuesday, 30 January 2018 at 19:19:39 UTC, Laeeth Isharc wrote:
 Every language is based on different principles.  The way D 
 will be adopted is via people who are principals giving it a 
 try because it solves their problems.

Not sure what you mean by principles, Algol languages (the class 
of languages D belongs to) tend be rather similar as far as 
principles for computation goes.

At the early stage adoption is rarely driven by management. 
Management tend to go with major players. In order to go with 
smaller players you need to appeal to engineering-aesthetics, not 
management constraints.

Both Rust and Go has gotten adoption along the 
engineering-aesthetics dimension. Very few management related 
advantages with those languages at the stage where D is at. 
Docker changed that a bit for Go, but that was after it had a 
fair following. Anyway, it also confirms the "you need a major 
application" assumption.

Although Python didn't have a major application when it was 
adopted. It was just better than Perl,  Php and Bash.

TooHuman <michael toohuman.io> writes:

On Sunday, 28 January 2018 at 18:54:34 UTC, Laeeth Isharc wrote:
 On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
 [...]

 That's what you would expect, because D is a very ambitious 
 language, which means its natural user base is much more spread 
 out and less highly concentrated.  And beyond that, most code 
 is enterprise code that's closed source, and whilst the web 
 guys talk a lot and influence the culture, enterprise guys talk 
 much less and just do their thing quietly.  Even in our world, 
 how often do you see the people using D get involved in forum 
 discussions?  Sociomantic, Weka, Ebay, and so on.  (Or 
 Microsoft - did you know that D was used in their COM team?  
 They didn't exactly send out a press release...)  A little bit, 
 but only a little in relation to their use of the language.  If 
 you're trying to accomplish something in a representative 
 enterprise context with lean resources, you don't have much 
 time to talk about what you are doing.

 [...]

You're absolutely right in that, for a language like D with such 
a broad range of features, that it should absolutely be marketed 
as a generalist language. However, the kinds of "killer apps" I 
think people are talking about, are likely referring to apps that 
simply shine a spotlight on D, and allow people to discover all 
of the things that they can also do in D. A variety of "killer 
apps" would therefore be helpful, but any attention shown to D 
would be good. At the moment, it feels like the language is 
somewhat peddling about but not really going anywhere. I'm sure, 
as we've seen from downloads and things, that this isn't exactly 
the case, but we're not seeing Go levels of adoption, or even 
Rust levels of adoption.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:

 section, because from my perspective it's receiving more and 
 more adoption as the modern alternative to Java, in a way that 
 Go and Rust are not. Different markets and all of that. So I 

 in popularity (though I don't use it myself).

I don't think the data suggests that? A small dip, perhaps, as it 
is less relevant outside Microsoft desktop. But the transition 





 I do worry that, having been using D for about 3 1/2 years now, 
 that the perceptions of D outside of this community don't seem 
 to be changing much.

But D isn't changing either...