www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How programmers transition between languages

reply 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.
Jan 26
next sibling parent reply 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.
Jan 26
next sibling parent reply 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.
Jan 26
parent reply 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
Jan 26
parent reply 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.
Jan 26
next sibling parent 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/
Jan 26
prev sibling parent 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
Jan 28
prev sibling next sibling parent reply 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.
Jan 26
parent reply 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() ```
Jan 27
parent reply 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,
Jan 27
parent reply 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.
Jan 27
parent reply 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.
Jan 28
parent 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.
Jan 28
prev sibling parent reply 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.
Jan 27
parent reply 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.
Jan 27
parent reply 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.
Jan 30
parent reply 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.
Jan 30
parent reply 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?
 [...]
Jan 30
parent 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
Jan 30
prev sibling next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
Very cool stuff, thanks for sharing.
Jan 26
prev sibling parent reply 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.
I find it fascinating that C# is in the "languages to avoid" 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 why C# would be seen as a language that is dropping 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.
Jan 28
next sibling parent 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:
 [...]
I find it fascinating that C# is in the "languages to avoid" 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 why C# would be seen as a language that is dropping in popularity (though I don't use it myself). [...]
Oh, I had confused Objective-C with C# in that graph. Forget the first part of my previous post.
Jan 28
prev sibling next sibling parent reply 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.
Jan 28
next sibling parent 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
Jan 28
prev sibling parent reply 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.
Jan 28
parent reply 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.
Jan 28
next sibling parent reply 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.
Jan 28
parent reply 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 Grstad

 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
Jan 28
parent reply 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.
Jan 28
parent reply 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.
Jan 29
parent reply 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.
Jan 30
parent 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.
Jan 30
prev sibling next sibling parent reply 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
Jan 29
parent reply 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.
Jan 30
parent 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
Jan 31
prev sibling parent reply 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.
Jan 29
parent 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.
Jan 30
prev sibling next sibling parent reply 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.
I find it fascinating that C# is in the "languages to avoid" 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 why C# would be seen as a language that is dropping 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.
Jan 28
parent reply 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.
Jan 28
next sibling parent reply 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
Jan 29
next sibling parent reply 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
Jan 29
parent reply 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
Jan 30
parent reply 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
Jan 30
next sibling parent reply 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.
Jan 30
parent 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.
Jan 30
prev sibling parent reply 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
Feb 01
next sibling parent 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
Feb 01
prev sibling parent reply 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
Feb 02
parent reply 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
Feb 02
parent 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
Feb 02
prev sibling parent 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.
Feb 01
prev sibling next sibling parent reply 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.
Jan 30
next sibling parent 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
Jan 30
prev sibling next sibling parent 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.
Jan 30
prev sibling parent reply 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.
Jan 30
parent 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.
Jan 30
prev sibling parent 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.
Jan 30
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
 I find it fascinating that C# is in the "languages to avoid" 
 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 why C# would be seen as a language that is dropping 
 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 matrix suggests that people move a bit between Java and C# and that people move from Pascal and Visual Basic to C#. I suspect some projects move from C# to TypeScript, though.
 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...
Jan 28