## digitalmars.D - Go 1.9

• Russel Winder via Digitalmars-d (13/13) Jun 19 Go gets parallel compilation, at last, and better garbage collection. Th...
• Bienlein (14/17) Jun 19 Right, D2 has a problem with the GC. It cannot be put to
• Jack Stouffer (4/5) Jun 19 Disagree. One of D's biggest competitive advantages is fast
• Michael (6/11) Jun 25 I think the problem with this is that compilation speed being the
• Jack Stouffer (6/12) Jun 26 I don't know where you're getting this idea that fast compile
• bpr (6/9) Jun 19 It should also be noted that, even though it's still a research
• Wulfklaue (3/8) Jun 19 Immix has a very impressive speed compared to default Boehm.
• Russel Winder via Digitalmars-d (26/37) Jun 19 I'd be more bothered by Kotlin native that Scala native.=20
• Wulfklaue (5/6) Jun 19 Thanks, did not even know that Jetbrain is also going for a
• Bienlein (12/15) Jun 22 In Java development there is almost no C or C++ and no Rust or D
• Wulfklaue (23/36) Jun 22 That is just sloppy... There is this bad trend in the industry,
• Laeeth Isharc (11/47) Jun 22 Massive relative price shocks can be important in shaping trends
• Russel Winder via Digitalmars-d (43/56) Jun 22 The whole "Just add more memory" approach of JVM installations leads to
• Paulo Pinto (22/37) Jun 22 This includes how Android developers see the use of the NDK, and I
• Russel Winder via Digitalmars-d (12/17) Jun 22 --=20
• Wulfklaue (10/16) Jun 22 Those are also the major players in the market. C# Microsoft,
• Paulo Pinto (15/28) Jun 22 Java is AOT compiled to native code via Excelsior JET, IBM J9,
• Araq (27/34) Jun 23 Have you used one of these products? How do they deal with
• Paulo Pinto (18/55) Jun 23 ExcelsiorJET is quite easy to figure out, you can download their
• Araq (20/33) Jun 23 So in other words, you do not have used these products and only
• Paulo Pinto (5/12) Jun 23 You are right, it was a mistake to come back to these forums,
• Bienlein (1/3) Jun 22 The memory footprint doesn't matter. Those times are OVER :-).
• Bienlein (7/10) Jun 22 Here are some references:
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (6/9) Jun 23 People said that 30 years ago too... It is still an issue,
• Bienlein (11/21) Jun 23 I have not done any manual memory management at work for the last
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (4/6) Jun 23 But are you doing any programming for the low end of the hardware
• Bienlein (3/9) Jun 23 I'm assuming that D is for general purpose programming as well.
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (3/4) Jun 24 That seems to be where it is heading. I don't think D stands a
• Ecstatic Coder (31/34) Jun 24 With all due respect, on the contrary I think that promoting D as
• Wulfklaue (57/79) Jun 24 I personally will not go that far. Syntax is more about
• rikki cattermole (4/9) Jun 24 What on earth are you talking about[0]?
• Wulfklaue (55/57) Jun 24 *wow* ... Call me amazed and dumbstruck.
• rikki cattermole (9/12) Jun 24 It's fine. You're not attacking anyone and not swearing for the sake of
• Adam D. Ruppe (27/34) Jun 24 It was somewhat active for a while a couple years ago, but I
• Andrei Alexandrescu (14/17) Jun 24 On 6/24/17 1:11 PM, Wulfklaue wrote:
• Wulfklaue (60/71) Jun 24 The issue with pure bounties is that while they may incentive
• Ecstatic Coder (11/94) Jun 24 I agree with all that you said.
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (6/15) Jun 24 Most programming languages are technically "general purpose", but
• Russel Winder via Digitalmars-d (21/28) Jun 24 On Sat, 2017-06-24 at 10:34 +0000, Ola Fosheim Gr=C3=B8stad via Digitalm...
• Ecstatic Coder (12/29) Jun 24 I agree, but it will be hard for D to beat C++, because people
• Laeeth Isharc (328/347) Jun 24 I know that in certain other sectors, people have high
• bachmeier (24/25) Jun 24 Integration with R is largely complete, but the missing piece has
• jmh530 (6/18) Jun 24 Music to my ears! Please put something up on announce when you
• Igor (23/23) Jun 25 Maybe I am wrong but I get a feeling from posts in this thread
• bachmeier (36/46) Jun 25 It will probably take a while to put together a formal release.
• jmh530 (21/30) Jun 26 You might make reference to cd to the folder that R.dll for x64
• bachmeier (6/10) Jun 26 Thanks for giving it a try. I have a feeling that this is a job
• jmh530 (4/9) Jun 26 I don't know how well dub will handle it as my dub projects never
• bachmeier (8/9) Jun 26 I think this will be fairly easily handled within the embedr R
• jmh530 (2/3) Jun 26 Great. I'll give it a go again when it's ready.
• bachmeier (6/10) Jun 27 You can try this:
• bachmeier (8/12) Jun 30 An update. It looks like I will be able to get all of my research
• jmh530 (2/9) Jul 02 Cool. I still need to give embedrwin a try...
• jmh530 (25/42) Jul 03 I just gave it a try. Got an error. As far as I can tell, the
• bachmeier (8/25) Jul 04 Thanks. I forgot a pair of quotes.
• Kagamin (3/6) Jun 23 Do you want D to compete in enterprise domain? Of 16 programs
• Joakim (17/24) Jun 23 Not only that, but the majority of use of Java and soon Kotlin is
• Paulo Pinto (4/30) Jun 23 C# lost the Longhorn/Vista battle, but won the Windows 10 UWP one.
• Joakim (19/31) Jun 23 I wouldn't say C# won, UWP is implemented in C++ and supports
• Paulo Pinto (3/10) Jun 22 Just like Java when one uses any commercial JDK or C# when
• Wulfklaue (7/8) Jun 23 Well, Kotlin/Native just came out with version 0.3. And it
• Ecstatic Coder (6/9) Jun 19 Indeed a faster garbage collector will be a good selling point
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
Go gets parallel compilation, at last, and better garbage collection. The
former is not a problem for D, but the latter=E2=80=A6

<probably-a-troll-but-still-worth-saying-that-gc-can-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=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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   voip:sip:
russel.winder ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:russel winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder

Jun 19
Bienlein <jeti789 web.de> writes:
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote:
Go gets parallel compilation, at last, and better garbage
collection. The former is not a problem for D, but the latter…

<probably-a-troll-but-still-worth-saying-that-gc-can-change/>

Right, D2 has a problem with the GC. It cannot be put to
reasonable speed, because of initial design decisions with D
memory management. If there is a reason for D3, then it is to
make the required changes so that the GC can be made faster.

The GC is in my opinion very important for the success of D. Go
is the best example that a programming language for "system-like"
programming can have a huge success out there in the real world.
If using the GC were problem free in D, a lot of projects that
chose Go might have gone with D. And there are tons of
applications out there that are the flag ship product of some
startup company that are written in Go.

So the best thing that can happen to D, IMHO, is that the GC
issue is resolved even if that required a move from D2 to D3.

Jun 19
Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote:
The former is not a problem for D, but the latter…

Disagree. One of D's biggest competitive advantages is fast
compilation of fast code. If other languages become as fast or
faster than DMD in compilation speed then that's a big problem.

Jun 19
Michael <michael toohuman.io> writes:
On Monday, 19 June 2017 at 15:07:12 UTC, Jack Stouffer wrote:
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote:
The former is not a problem for D, but the latter…

Disagree. One of D's biggest competitive advantages is fast
compilation of fast code. If other languages become as fast or
faster than DMD in compilation speed then that's a big problem.

I think the problem with this is that compilation speed being the
no. 1 selling point requires people to invest in large projects
in order to reap the benefits. However, if you fail to draw them
in to begin with, then they're not going to commit to a large
enough project to benefit enough from improved compilation speed.

Jun 25
Jack Stouffer <jack jackstouffer.com> writes:
On Sunday, 25 June 2017 at 17:21:06 UTC, Michael wrote:
I think the problem with this is that compilation speed being
the no. 1 selling point requires people to invest in large
projects in order to reap the benefits. However, if you fail to
draw them in to begin with, then they're not going to commit to
a large enough project to benefit enough from improved
compilation speed.

I don't know where you're getting this idea that fast compile
times only help for large projects.

I reap the benefits every time I use rdmd for my scripts. I reap
the benefits every time the compilation is near instant when
tweaking+debugging my libraries or when unit testing my projects.

Jun 26
bpr <brogoff gmail.com> writes:
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote:
Go gets parallel compilation, at last, and better garbage
collection. The former is not a problem for D, but the latter…

<probably-a-troll-but-still-worth-saying-that-gc-can-change/>

It should also be noted that, even though it's still a research
project, Scala native just recently upgraded it's Boehm GC to an
Immix based one. Scala native would be yet another language
competing with D, and might compete in even more domains than Go
would.

Jun 19
Wulfklaue <wulfklaue wulfklaue.com> writes:
On Monday, 19 June 2017 at 15:44:47 UTC, bpr wrote:
It should also be noted that, even though it's still a research
project, Scala native just recently upgraded it's Boehm GC to
an Immix based one. Scala native would be yet another language
competing with D, and might compete in even more domains than
Go would.

Immix has a very impressive speed compared to default Boehm.

http://img.phperz.com/data/img/20170616/1497580303_4280.png

Jun 19
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2017-06-19 at 15:44 +0000, bpr via Digitalmars-d wrote:
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote:
Go gets parallel compilation, at last, and better garbage=20
collection. The former is not a problem for D, but the latter=E2=80=A6
=20
<probably-a-troll-but-still-worth-saying-that-gc-can-change/>

=20
It should also be noted that, even though it's still a research=20
project, Scala native just recently upgraded it's Boehm GC to an=20
Immix based one. Scala native would be yet another language=20
competing with D, and might compete in even more domains than Go=20
would.

I'd be more bothered by Kotlin native that Scala native.=20

Scala did a lot for the JVM in terms of getting "functional" accepted as a
word that wasn't a swear word. However it is a very complicated language.
Kotlin is a great "half way house" in replacing Java but not being as
complicated as Scala but with the same "functional objects" approach that
Scala started and championed. Scala trieed as yet.d to be and now Kotlin ha=
s
become the language of choice for the discerning JVM-oriented Android
developer.

With Kotlin Native now announced and going great guns, it may be that C++,
D, Rust, and Go, get a challenge that Scala Native has not managed.

I suspect though that like Go took Python more than C folk, Kotlin Native
will take more Java that C++, Go and Rust folks. But speculation rarely tur=
n
out quite as speculated.

--=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=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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   voip:sip:
russel.winder ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:russel winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder

Jun 19
Wulfklaue <wulfklaue wulfklaue.com> writes:
On Monday, 19 June 2017 at 16:13:20 UTC, Russel Winder wrote:
I'd be more bothered by Kotlin native that Scala native.

Thanks, did not even know that Jetbrain is also going for a
native LLVM version. It even seems they are in contact with the
Scala-native team. Looks like everybody is jumping on the native
LLVM compilation bandwagon.

Jun 19
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2017-06-19 at 19:17 +0000, Wulfklaue via Digitalmars-d wrote:
On Monday, 19 June 2017 at 16:13:20 UTC, Russel Winder wrote:
I'd be more bothered by Kotlin native that Scala native.

=20
Thanks, did not even know that Jetbrain is also going for a=C2=A0
native LLVM version. It even seems they are in contact with the=C2=A0
Scala-native team. Looks like everybody is jumping on the native=C2=A0
LLVM compilation bandwagon.

It seems the logical next step for development of IntelliJ IDEA, and
all the other IDEs, remove the JVM from the equation. It's an obvious
long-term plan.

ACCU 2018.

--=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=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Jun 19
Bienlein <jeti789 web.de> writes:
 I suspect though that like Go took Python more than C folk,
Kotlin Native will take more Java that C++, Go and Rust folks.
But speculation rarely turn out quite as speculated.

In Java development there is almost no C or C++ and no Rust or D
at all. Memory is no problem. Some server needs 256 GB RAM or
maybe 512 GB? That's not an issue anywhere. As long as you get
the performance through parallelisation there is no need for C or
C++.

You won't meet any Java EE archtitecture that will do anything
else than fight against calling C, C++ routines from Java. That
is only done in some very exceptional cases.

The days of languages for systems programming are over. There are
only very few people that need such a language. That is why D
really needs a decent GC, otherwise it won't find any users that
would do production systems with it.

Jun 22
Wulfklaue <wulfklaue wulfklaue.com> writes:
On Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote:
In Java development there is almost no C or C++ and no Rust or
D at all. Memory is no problem. Some server needs 256 GB RAM or
maybe 512 GB?

That is just sloppy... There is this bad trend in the industry,
it has been going on for years. Performance issue, trow more
hardware at the problem. Optimizations? Trow more hardware at the
issue.

The problem being that it has becomes a constantly lowering
expectations bar. Hire some basic programmers, use
php/ruby/python and performance issues are simply overlooked as
part of the job.

In my daily job seeing php import scripts that suck up a GB just
for some basic work, is considered almost normal. Let the client
pay for more performing servers. Our developers need to write
more code, faster, be ready before the deadline so we can bill
the client for the fast work.

That's not an issue anywhere. As long as you get the
performance through parallelisation there is no need for C or
C++.

And while this works on a local server, the moment you start with
clusters, master-slave configurations etc, things get complicated
fast. Especially with latency issues.

You won't meet any Java EE archtitecture that will do anything
else than fight against calling C, C++ routines from Java. That
is only done in some very exceptional cases.

That same applies to just about every other language. Native will
always be prioritized before external calls.

The days of languages for systems programming are over. There
are only very few people that need such a language. That is why
D really needs a decent GC, otherwise it won't find any users
that would do production systems with it.

Technically, with Go, Rust, Crystal etc more about those high
performing languages, then before. Before it was all about
scripting languages, slowly you see a trend backing away from
them.

Jun 22
Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Thursday, 22 June 2017 at 07:32:51 UTC, Wulfklaue wrote:
On Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote:
In Java development there is almost no C or C++ and no Rust or
D at all. Memory is no problem. Some server needs 256 GB RAM
or maybe 512 GB?

That is just sloppy... There is this bad trend in the industry,
it has been going on for years. Performance issue, trow more
hardware at the problem. Optimizations? Trow more hardware at
the issue.

The problem being that it has becomes a constantly lowering
expectations bar. Hire some basic programmers, use
php/ruby/python and performance issues are simply overlooked as
part of the job.

In my daily job seeing php import scripts that suck up a GB
just for some basic work, is considered almost normal. Let the
client pay for more performing servers. Our developers need to
write more code, faster, be ready before the deadline so we can
bill the client for the fast work.

That's not an issue anywhere. As long as you get the
performance through parallelisation there is no need for C or
C++.

And while this works on a local server, the moment you start
with clusters, master-slave configurations etc, things get
complicated fast. Especially with latency issues.

You won't meet any Java EE archtitecture that will do anything
else than fight against calling C, C++ routines from Java.
That is only done in some very exceptional cases.

That same applies to just about every other language. Native
will always be prioritized before external calls.

The days of languages for systems programming are over. There
are only very few people that need such a language. That is
why D really needs a decent GC, otherwise it won't find any
users that would do production systems with it.

Technically, with Go, Rust, Crystal etc more about those high
performing languages, then before. Before it was all about
scripting languages, slowly you see a trend backing away from
them.

Massive relative price shocks can be important in shaping trends
in the use of technology.  Storage prices drop 40% annually,
Moore'a Law isn't what it was, and dram latency isn't improving
nearly as fast as data sets are increasing in size.  Intel non
volatile storage technology upsets all our assumptions about
where the bottlenecks are, and there seems a decent chance that
as you say the tilt away from slow languages is only just
beginning.

Acam paper linked at the end of this.

Jun 22
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2017-06-22 at 07:15 +0000, Bienlein via Digitalmars-d wrote:
=20

[=E2=80=A6]
In Java development there is almost no C or C++ and no Rust or D=C2=A0
at all. Memory is no problem. Some server needs 256 GB RAM or=C2=A0
maybe 512 GB? That's not an issue anywhere. As long as you get=C2=A0
the performance through parallelisation there is no need for C or=C2=A0
C++.

The whole "Just add more memory" approach of JVM installations leads to
some really crap programs and programming. And what is worse, they do
not even do parallelism properly. Whenever I did Java workshops, I was
programmers were. I.e. the average Java programmer is really not very
good.

A fairly good metric in the UK is, if a supposed Java programmer hasn't
heard of DevoxxUK or JAXLondon or has heard of them but doesn't want to
go, then they are not a Java programmer, they are just robots turning
out Java code, disinterested in their profession..=20

You won't meet any Java EE archtitecture that will do anything=C2=A0
else than fight against calling C, C++ routines from Java. That=C2=A0
is only done in some very exceptional cases.

Same goes for people sensibly avoiding Java EE and using Springboot or
container-base system, even those using Tomcat. JNI is horrible, to be
used only if absolutely necessary. Hence JNA, JNR, etc. all designed to
make FFI easier with the JVM. The next round of Charlie Nutter's
assault on JVM FFI may make things a lot better.

The days of languages for systems programming are over. There are=C2=A0
only very few people that need such a language. That is why D=C2=A0
really needs a decent GC, otherwise it won't find any users that=C2=A0
would do production systems with it.

It depends what you mean by systems programming. Go folk for example
seems to thing anything to do with The Web is systems programming.

Whilst many people see The Web as the only thing that programmers do, I
bet that most software has nothing to do with it. JVM-based system
account for a lot, but it is nearly all Web oriented. Python has
hegemony currently (but not for long I'll wager) in AI and machine
learning. Many, including some Scala and Kotlin folk see the
constraints of the JVM (that containers, Docker, and Kubernetes have
quite nicely highlighted) =E2=80=93 native code is resurgent.

But yes, there are different forms of native code, and I agree, there
are places where a GC cannot be used (hard real time currently, but
people are working on that, again cf. Go folk), and the rest where GC
is a good thing. But only a good GC is a good thing =E2=80=93 this lesson c=
omes
from 20 years of JVM. The JVM has encouraged research and
implementation of GCs.

--=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=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Jun 22
Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote:
I suspect though that like Go took Python more than C folk,
Kotlin Native will take more Java that C++, Go and Rust folks.
But speculation rarely turn out quite as speculated.

In Java development there is almost no C or C++ and no Rust or
D at all. Memory is no problem. Some server needs 256 GB RAM or
maybe 512 GB? That's not an issue anywhere. As long as you get
the performance through parallelisation there is no need for C
or C++.

You won't meet any Java EE archtitecture that will do anything
else than fight against calling C, C++ routines from Java. That
is only done in some very exceptional cases.

This includes how Android developers see the use of the NDK, and I
quote:

"""
Squeeze extra performance out of a device to achieve low latency
or run computationally intensive applications, such as games or
physics simulations.

Reuse your own or other developers' C or C++ libraries.
"""

https://developer.android.com/ndk/guides/index.html

Anything else is frowned upon and only available to Java,
requiring JNI calls to access the features from C and C++.

They even pivoted Brillo from a being a simplified Android with
C++ Framework, to a simplified Android where even user space
drivers can be written in Java.

https://developer.android.com/things/sdk/drivers/index.html

The days of languages for systems programming are over. There
are only very few people that need such a language. That is why
D really needs a decent GC, otherwise it won't find any users
that would do production systems with it.

This was quite visible at this year's WWDC, Google IO and BUILD.

They were all about Swift, Java, Kotlin, C#.

There were hardly any meaningful talks with C or C++ content
related to actual software development on their OSes, other than
to share the latest improvements in compiler/IDE tooling and ANSI
C++ compliance.

Jun 22
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2017-06-22 at 10:00 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]
=20
They were all about Swift, Java, Kotlin, C#.
=20

Isn't Swift a native code language?
=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=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Jun 22
Wulfklaue <wulfklaue wulfklaue.com> writes:
On Thursday, 22 June 2017 at 10:23:37 UTC, Russel Winder wrote:
On Thu, 2017-06-22 at 10:00 +0000, Paulo Pinto via
Digitalmars-d wrote:
[…]

They were all about Swift, Java, Kotlin, C#.

Those are also the major players in the market. C# Microsoft,
Swift Apple, Java Oracle... so there is more focus on them
naturally.

Isn't Swift a native code language?

Yep ... Its it uses LLVM.

Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)

C# may change to a native compiled language with CoreRT ( This
translates C# to C++ code and then compiles it. A bit like Haxe
(C++ target) or Nim(C target) ).

Jun 22
Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 22 June 2017 at 11:11:01 UTC, Wulfklaue wrote:
On Thursday, 22 June 2017 at 10:23:37 UTC, Russel Winder wrote:
On Thu, 2017-06-22 at 10:00 +0000, Paulo Pinto via
Digitalmars-d wrote:
[…]

They were all about Swift, Java, Kotlin, C#.

Those are also the major players in the market. C# Microsoft,
Swift Apple, Java Oracle... so there is more focus on them
naturally.

Isn't Swift a native code language?

Yep ... Its it uses LLVM.

Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)

Java is AOT compiled to native code via Excelsior JET, IBM J9,
IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART and
eventually Java 10.

Sun was the only one religilous against any kind of AOT support,
all major commercial JDKs always supported AOT compilation.

C# is AOT compiled to native code since day 1, via NGEN, althouth
it isn't an optimizing compiler and only supports dynamic linking.

C# and VB.NET for Windows 8 and Windows 8.1 only support AOT
compilation to native code via a format called MDIL (Machine
Dependent Intermediate Language), basically native code with
symbolic labels, linked on the devices at installation time.

C# and VB.NET for UWP are always AOT compiled to native code and

Better learn what the competition is actually doing.

Jun 22
Araq <rumpf_a web.de> writes:
On Thursday, 22 June 2017 at 11:27:47 UTC, Paulo Pinto wrote:
Java is AOT compiled to native code via Excelsior JET, IBM J9,
IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART and
eventually Java 10.

Have you used one of these products? How do they deal with

C# is AOT compiled to native code since day 1, via NGEN,
althouth it isn't an optimizing compiler and only supports

From
https://docs.microsoft.com/en-us/dotnet/framework/net-native/net-native-and-compilation

"Because the .NET Native tool chain links implementation code
into your app only if it knows that your app actually invokes
that code, either the metadata or the implementation code
required in the following scenarios may not be included with your
app:

* Reflection.
* Dynamic or late-bound invocation.
* Serialization and deserialization.
* COM interop.

If the necessary metadata or implementation code is absent at
runtime, the .NET Native runtime throws an exception. You can
prevent these exceptions, and ensure that the .NET Native tool
chain includes the required metadata and implementation code, by
using a runtime directives file, an XML file that designates the
program elements whose metadata or implementation code must be
available at runtime and assigns a runtime policy to them. The
following is the default runtime directives file that is added to
a Windows Store project that is compiled by the .NET Native tool
chain: ..."

Better learn what the competition is actually doing.

and Java and do not work well with AOT compilation and never
will. Money can't patch over design mistakes.

Jun 23
Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 23 June 2017 at 19:27:56 UTC, Araq wrote:
On Thursday, 22 June 2017 at 11:27:47 UTC, Paulo Pinto wrote:
Java is AOT compiled to native code via Excelsior JET, IBM J9,
IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART
and eventually Java 10.

Have you used one of these products? How do they deal with

open source version.

Some products go the static linking way, others map .jars into
shared libraries.

C# is AOT compiled to native code since day 1, via NGEN,
althouth it isn't an optimizing compiler and only supports

From
https://docs.microsoft.com/en-us/dotnet/framework/net-native/net-native-and-compilation

"Because the .NET Native tool chain links implementation code
into your app only if it knows that your app actually invokes
that code, either the metadata or the implementation code
required in the following scenarios may not be included with

* Reflection.
* Dynamic or late-bound invocation.
* Serialization and deserialization.
* COM interop.

If the necessary metadata or implementation code is absent at
runtime, the .NET Native runtime throws an exception. You can
prevent these exceptions, and ensure that the .NET Native tool
chain includes the required metadata and implementation code,
by using a runtime directives file, an XML file that designates
the program elements whose metadata or implementation code must
be available at runtime and assigns a runtime policy to them.
The following is the default runtime directives file that is
added to a Windows Store project that is compiled by the .NET
Native tool chain: ..."

Better learn what the competition is actually doing.

and Java and do not work well with AOT compilation and never
will. Money can't patch over design mistakes.

Nice how you overlook the fact that .NET Native requires static
linking, hence why there are such issues.

AOT compiling to native code with either NGEN or Windows 8 MDIL
compiler doesn't have such issues, because dynamic linking is

Also .NET Native is still kind of work in progress, as they still
try to bring more features from System C# into regular .NET
toolchain. With every Windows 10 SDK release there are new

In any case, even if native compilation toolchains for Java and
C# aren't perfect, they make it less appealing to try out D if
you don't come up with a solid history to go against them, that
make people actually curious to try out D.

Jun 23
Araq <rumpf_a web.de> writes:
On Friday, 23 June 2017 at 20:13:15 UTC, Paulo Pinto wrote:
their open source version.

So in other words, you do not have used these products and only

Some products go the static linking way, others map .jars into
shared libraries.

And how does the tool know which .jars to compile to shared
libraries without running the code first? It can't. Which is why
Excelsior ships with a JIT:

From https://www.excelsiorjet.com/

"First, the AOT compiler turns your jar and class files into a
conventional binary executable. That executable is fully
interoperable with our JVM, which includes a JIT compiler to
handle any classes that were not precompiled."

Nice how you overlook the fact that .NET Native requires static
linking, hence why there are such issues.
AOT compiling to native code with either NGEN or Windows 8 MDIL
compiler doesn't have such issues, because dynamic linking is

Again, how can you compile ahead-of-time when you don't know the
dependencies before running the program? You can't which is why
every such tool is at a fight with how these languages work.

In any case, even if native compilation toolchains for Java and
C# aren't perfect, they make it less appealing to try out D if
you don't come up with a solid history to go against them, that
make people actually curious to try out D.

That's just "I looked at the websites, never used these tools in
practice but found them convincing" phrased differently to
pretend you have an argument.

The success of Go strongly indicates people generally don't
connect Java/C# to "native code" or "slim binaries without
dependencies", whom are you kidding here.

Jun 23
Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 23 June 2017 at 21:31:00 UTC, Araq wrote:
...

That's just "I looked at the websites, never used these tools
in practice but found them convincing" phrased differently to
pretend you have an argument.

The success of Go strongly indicates people generally don't
connect Java/C# to "native code" or "slim binaries without
dependencies", whom are you kidding here.

You are right, it was a mistake to come back to these forums,
after the GDC announcement.

Looking forward to see blazing fast D applications on the Windows
store.

Jun 23
Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 23 June 2017 at 22:38:29 UTC, Paulo Pinto wrote:
On Friday, 23 June 2017 at 21:31:00 UTC, Araq wrote:
...

That's just "I looked at the websites, never used these tools
in practice but found them convincing" phrased differently to
pretend you have an argument.

The success of Go strongly indicates people generally don't
connect Java/C# to "native code" or "slim binaries without
dependencies", whom are you kidding here.

You are right, it was a mistake to come back to these forums,
after the GDC announcement.

Looking forward to see blazing fast D applications on the
Windows store.

Just FYI, Araq is the author of Nim (https://nim-lang.org/), so
I'm sure he didn't have any intention in making D look good ;)

On the other hand, I think he made good technical arguments,
(leaving
aside his Ad Hominem way of expressing, which I think was out of
place) which I think you should actually consider.

Jun 23
Bienlein <jeti789 web.de> writes:
 Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)

The memory footprint doesn't matter. Those times are OVER :-).

Jun 22
Bienlein <jeti789 web.de> writes:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)

The memory footprint doesn't matter. Those times are OVER :-).

Here are some references:

http://benchmarksgame.alioth.debian.org/u64q/go.html
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc

There you can see how little memory Go uses compared to C and
Java. Java will also get better as it will also get value types
in some upcoming JDK.

Jun 22
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)

The memory footprint doesn't matter. Those times are OVER :-).

People said that 30 years ago too... It is still an issue,
though. Not as much as it was, but still relevant.

Programmers seem to be able to suck up whatever RAM is available
on the low-end by adding frameworks, bloated libraries and
runtimes, or just bugs…

Jun 23
Bienlein <jeti789 web.de> writes:
On Friday, 23 June 2017 at 08:57:04 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)

The memory footprint doesn't matter. Those times are OVER :-).

People said that 30 years ago too... It is still an issue,
though. Not as much as it was, but still relevant.

Programmers seem to be able to suck up whatever RAM is
available on the low-end by adding frameworks, bloated
libraries and runtimes, or just bugs…

I have not done any manual memory management at work for the last
25 years. Did some C++ programming at college and a bit at home
where I had to take care of memory myself. That was it. Till I
retire in 20 years I will also not have been doing any manual
memory management. That kind of stuff only survives in very
special areas where 0.1% of all software developers work.

That being said let me repeat that D needs a decent GC for being
able to create any traction, because those 99.9% of the share are
the far bigger market.

Jun 23
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 23 June 2017 at 11:15:40 UTC, Bienlein wrote:
I have not done any manual memory management at work for the
last 25 years.

But are you doing any programming for the low end of the hardware
spectrum? It has been the low end hardware limitations that have
the standard for memory consumption…

Jun 23
Bienlein <jeti789 web.de> writes:
On Friday, 23 June 2017 at 14:07:09 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 23 June 2017 at 11:15:40 UTC, Bienlein wrote:
I have not done any manual memory management at work for the
last 25 years.

But are you doing any programming for the low end of the
hardware spectrum? It has been the low end hardware limitations
that have the standard for memory consumption…

I'm assuming that D is for general purpose programming as well.

Jun 23
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 23 June 2017 at 14:45:12 UTC, Bienlein wrote:
I'm assuming that D is for general purpose programming as well.

That seems to be where it is heading.  I don't think D stands a
chance in that domain, but we'll see.

Jun 24
Ecstatic Coder <ecstatic.coder gmail.com> writes:
 I'm assuming that D is for general purpose programming as well.

That seems to be where it is heading.  I don't think D stands a
chance in that domain, but we'll see.

With all due respect, on the contrary I think that promoting D as
a general purpose programming language could be its only chance
to really improve its popularity, and thus significantly grow its
current user base.

I'm sorry to repeat myself once again on this forum, but it's
obvious to me that D's strongest feature at the moment is that it
has the best syntax on the market.

Reference types, strings, maps, slices, arrays, UFCS, etc,
will work both safely and efficiently.

There is absolutely zero syntactic noise, the code is crystal
clear.

So instead of losing many potential users by focusing on a niche
market (unhappy C++ programmers), D should focus on its major
strengths, which already now make it stand high above its
competition.

For instance, all these programmer-friendly features make D even
more convenient for scripting than scripting languages themselves.

Just add the instant compilation, and you actually have the
perfect language for scripters and learning/inexperienced
programmers who currently choose JavaScript, Python, Ruby because
they don't know that the perfect language for their needs is
actually D.

I strongly believe that D has the potential to be the killer
"general purpose" language if :
1/ it is also promoted with this target in mind
2/ a few additional pre-installed libraries (web + ui) would make
it as easy to develop cross-platform connected applications.

IMHO, trying to compete directly with C++, C# and Java, with the
current state of the language and of its ecosystem, is simply
choosing the hardest path to success...

Jun 24
Wulfklaue <wulfklaue wulfklaue.com> writes:
On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote:
With all due respect, on the contrary I think that promoting D
as a general purpose programming language could be its only
chance to really improve its popularity, and thus significantly
grow its current user base.

I'm sorry to repeat myself once again on this forum, but it's
obvious to me that D's strongest feature at the moment is that
it has the best syntax on the market.

I personally will not go that far. Syntax is more about
preference. Rust looks dog ugly to me and yet some people find it
beautiful.

Personally i find Swift / Kotlin a nicer looking syntax then D.

Reference types, strings, maps, slices, arrays, UFCS, etc,
will work both safely and efficiently.

There is absolutely zero syntactic noise, the code is crystal
clear.

So instead of losing many potential users by focusing on a
niche market (unhappy C++ programmers), D should focus on its
major strengths, which already now make it stand high above its
competition.

Agrees with that. The problem with a language trying to scope
away a specific group of developers, from a existing ecosystem is
that your fighting the entire ecosystem, not just the language.
That is a mistake that many new languages make.

Why switch over from C++ to D?

Language => Sure.
Tooling => No.
Libraries => No.
Editors => No.
...

That has been the dilemma that not only D has faced. Until you
get critical mass where people start writing a massive amount of
your ecosystem, its hard to get people to switch over.

For instance, all these programmer-friendly features make D
even more convenient for scripting than scripting languages
themselves.

True but the same can be said about Go. And Go is even more
friendly and has the ecosystem now. You want to write something
more exotic. There is big change that somebody wrote a
module/package in Go. That is not going on with D. Sure, you can
take a existing c library and transform it into D but it still
takes work and is not always 100% idiomatic D.

That is the main difference between D and lets say Kotlin. Kotlin
build on top of Java and you can native imports all the
libraries. There is less effort involved.

Maybe this was mentioned before but a lot of programmers prefer
to lazy program. They want to write there code, move forward with
there project and not spend time on trying to get "things" to
import/convert/work. D has more people who have no issue doing
things the "hard" way. I applaud that resolve, i really do. But
at the same time its a barrier, a attitude that makes it hard to
accept those lazy people like me :)

IMHO, trying to compete directly with C++, C# and Java, with
the current state of the language and of its ecosystem, is
simply choosing the hardest path to success...

See above. Some people prefer the hard way. The masochists
*haha*. I know the angle where your coming from Ecstatic but its
hard to convince people. Especially when there is a manpower
shortage.

Frankly, i think the best way to go about moving D to popularity,
is simply money. More fully time programmers but that requires
money.

I do not understand why D does not have a BountySource account (
salt.bountysource.com ).

Look at nim ( $1,896 last month ) /crystal ($2,345 this month ):

They publish there fund raising. They motivate people by pointing
out the backers. Their income is a extra full time developer (
who wants to work for cheap :) ). The whole D foundation is nice
and well but to me it feels like cloak and daggers. It something
hiding in the background, something obscure. Maybe i am not
expressing myself good again but D its fund raising seems to be
largely corporate focused but they seem to lose a big market
potential. Corporate funding is harder to get then a lot of small
donations.

Its just my two cents but if D wants to grow, it needs full time
developers. Not just volunteer work. People who can do the grunt
work that volunteers do not want to do ( because its just not
sexy ).

Jun 24
rikki cattermole <rikki cattermole.co.nz> writes:
On 24/06/2017 11:17 AM, Wulfklaue wrote:

snip

Frankly, i think the best way to go about moving D to popularity, is
simply money. More fully time programmers but that requires money.

I do not understand why D does not have a BountySource account (
salt.bountysource.com ).

What on earth are you talking about[0]?

[0] https://www.bountysource.com/teams/d

Jun 24
Wulfklaue <wulfklaue wulfklaue.com> writes:
On Saturday, 24 June 2017 at 10:21:50 UTC, rikki cattermole wrote:
What on earth are you talking about[0]?

[0] https://www.bountysource.com/teams/d

*wow* ... Call me amazed and dumbstruck.

I never considered that D has a bountysource account. Its way,
waaaay at the bottom of the monthly listing page. It did not even
show up until 3 days ago.

This is just ... /lost for words and that is a first.

There is like one contribution 3 days ago and the last activity
is 8 months. No open contributions in the last 2+ years. *wow*
... just *wow* ...

Now i understand why some people complained that people if they
wanted something, that they needed to pay for it. Expect people
forgot to mention every time WHERE to put the payment. FFS ... i
had people tell me several times pay for whatever feature and not
a single person mention that D has a bountysource account.

Where is it even on the website????

Other sites:
============

Nim, one click on sponsors ( Top Page ) shows the sponsors and
amounts or a big donate button ( bottom page ).

Crystal, one click ( Top Page ) shows the sponsors and amounts.

D, ... press Community, then press Donate. Already two clicks,
hidden in the drop down menu.

https://dlang.org/donate.html

A big wall of text, no mention of donators, there amount. And
then paypal but no bountysource...

Electronic wire transfer or bank check *bwahaaha*. What are we:
1980? Even worse, "Wire transfer information will be announced
soon.". How long as that text been there??? Does the D team even
look at there own website???

No offense but frankly, this is the equivalent of not having a
bountysource account. Its simply hidden. There is no sponsors
list, there is no motivation if people donate like "hey, my name
is on the sponsor list". Or "hey, look, i am the top sponsor this
month".

For your information, i am still on the Nim list ;)

----

I was under the impression that D with a bountysource account was
going to be able to raise monthly funds on a higher level then
Crystal and Nim. I really do not know what to say. No wonder when
most new people do not even know its exists and the lack of
acknowledgment on the website only reinforces this.

There is no focus on raising funds. I talked about D Foundation
being obscure but this blow my mind. Talk about lost
opportunities on the website and general marketing.

A community project that wants to grow but does not take its
fundraising seriously... No no!!! Do not give me the party line:
if you want it solved, then enhance the website. This is part of
the core team there job. Its frankly the D Foundation there core
job to ensure every left and right way money can be gained, so
more people can be hired.

And sorry for the strong language but this is the truth! The fact
that i as a newcomer needs to point this out is just ridiculous.
Its easy to see why Nim and Crystal out fund D on bountysource.

Jun 24
rikki cattermole <rikki cattermole.co.nz> writes:
On 24/06/2017 1:11 PM, Wulfklaue wrote:

snip

And sorry for the strong language but this is the truth! The fact that i
as a newcomer needs to point this out is just ridiculous. Its easy to
see why Nim and Crystal out fund D on bountysource.

It's fine. You're not attacking anyone and not swearing for the sake of
swearing :)

My recommendation is to fund specific people or donate directly to the D
foundation. If there were people willing to fund specific people, it'll
pick up in time. As it stands it is mostly behind closed doors and going
straight to the people.

How to improve this without a giant wad of cash idk.

Jun 24
Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 24 June 2017 at 12:11:29 UTC, Wulfklaue wrote:
I never considered that D has a bountysource account. Its way,
waaaay at the bottom of the monthly listing page. It did not
even show up until 3 days ago.

It was somewhat active for a while a couple years ago, but I
found it to be simply offensive and a demotivator. They
(including a large corporation that you've heard of having
gigabucks) attached $50 bounties to bugs that would take several days of work to fix... then, of course, you have to go though the review process which has an indeterminate wait and frequently shifts goalposts. If any other client treated me like that, I'd walk away and never look back. (Heck, if any other client offered me what amounted to maybe$5 / hour, I'm not even sure that I'd waste my time
actually telling them no - I might just ignore their emails as

Bountysource has changed since then, and now has the salt
program, but I think I'm not the only one who found it
counterproductive in its early iteration and finds the brand
damaged. If we wanted to revive it, it'd have to be clearly done
differently than it was before.

Electronic wire transfer or bank check *bwahaaha*. What are we:
1980?

That's the way big donors actually prefer do business. Avoids
having x% of their donation go to some for-profit middleman, and
is easier accounting with the IRS. (D, being a legally
incorporated not-for-profit organization, is required by US law
to keep track of its financial information and publish an open
report each year. Also, individuals and businesses donating to it
can list that as a tax-deductible expense on their own annual
returns - provided they have the necessary documentation.)

There is no focus on raising funds. I talked about D Foundation
being obscure but this blow my mind.

Perhaps we need a new director of development!

Jun 24
Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 6/24/17 1:11 PM, Wulfklaue wrote:
[snip]

Thanks, this is a good point. The bountysource has been tried by
Facebook (with D and other projects) and was deemed unsuccessful. It may
be the time for trying a new angle on bountysource though.

We'll look into defining a page listing existing sponsors (though the
majority by monies are anonymous) and a simple method to donate on the
website.

Electronic wire transfer or bank check *bwahaaha*. What are we: 1980?

What other methods of payments do you have in mind?

Even worse, "Wire transfer information will be announced soon.". How
long as that text been there???

That's not much to worry about - we did have a few wire transfers; it's
not like people who want to wire us money have difficulty reaching us
for details. Nevertheless we need to update that.

Thanks,

Andrei

Jun 24
Wulfklaue <wulfklaue wulfklaue.com> writes:
On Saturday, 24 June 2017 at 21:56:20 UTC, Andrei Alexandrescu
wrote:
On 6/24/17 1:11 PM, Wulfklaue wrote:
[snip]

Thanks, this is a good point. The bountysource has been tried by
Facebook (with D and other projects) and was deemed
unsuccessful. It may
be the time for trying a new angle on bountysource though.

The issue with pure bounties is that while they may incentive
people if the work vs reward is good. But unfortunately, when
reading the bounties currently posted, a lot seem to be major
amount of time vs little pay.

That is why Nim / Crystal simply work with collecting money to
pay developers for specific bounties or pay for full time people.
It does not prevent people from doing there own bounties if they
want.

We'll look into defining a page listing existing sponsors
(though the majority by monies are anonymous) and a simple
method to donate on the website.

As seen with Nim, Crystal, ... there are plenty of people who do
not have a issue given a name or nickname. I think the current
reason for a lot of anonymous donation is simply there is no real
"advantage" for that person to have his/her name known.

People are competitive animals. If you see what amount of money
people sometimes donate to  ( small ) youtube'rs. Sometimes
thousand of dollars. All for being grateful by the person
receiving the money and being the top donater.

What other methods of payments do you have in mind?

Germany: www.sofort.com
Netherlands: www.ideal.nl
...

Those are all popular in there respected countries. At times
bigger then paypal etc...

Nevertheless we need to update that.

Might be interesting to also move the donation a bit more
"visual" on the website. Its not the first time that issues
regarding the website have been mentioned.

* The library still using the horrible phobos/index.html 101 page
library. There is now a link to the library/index.html that is
way better. But its something that most people will overlook.

* Tutorials:

I found the old:

https://www.tutorialspoint.com/d_programming/d_programming_associative_arrays.htm

A more interesting spot to actually learn D examples, then the D
website /spec/class.html. It more messy and finding out about
sometimes as simply as associative_arrays, only to discover that
its buried somewhere.

* It might also be interesting to do a "Rust" and have Ali's D
book provided as a standard free D book ( and maybe pay him
or forum knowledge to find out the book is also available for
free. Make it a prominent feature item on the website. Worth a
extra blog post = free publicity again. :)

* Local language websites.

As somebody with family relations in China, i can say that there
is a thriving Go community in China, where most Go related
documentation got translated. Unfortunately, its a bit of
"western" thinking, that everybody speaks / reads on a good level
English. By not having localized language versions of major
markets, D loses out on target audience. Go had the luxury that a
lot of people comited time to do the translations and was
rewarded with a large Go community in China. Something that most
western developer do not even realize how big Go is in China. The
idea that every software  developer knows (any/good ) English is
sometimes a bit exaggerated. So this is again a overlooked
potential focus point.

... Plenty of topics regarding the website around ;)

My biggest advice is to find or hire a community director.
Somebody who's job is community management, media management, to
focus resources etc. Some of the things that i mention seem to
have been mentioned a lot of times before.

Jun 24
Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Saturday, 24 June 2017 at 10:17:16 UTC, Wulfklaue wrote:
On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote:
With all due respect, on the contrary I think that promoting D
as a general purpose programming language could be its only
chance to really improve its popularity, and thus
significantly grow its current user base.

I'm sorry to repeat myself once again on this forum, but it's
obvious to me that D's strongest feature at the moment is that
it has the best syntax on the market.

I personally will not go that far. Syntax is more about
preference. Rust looks dog ugly to me and yet some people find
it beautiful.

Personally i find Swift / Kotlin a nicer looking syntax then D.

Reference types, strings, maps, slices, arrays, UFCS, etc,
will work both safely and efficiently.

There is absolutely zero syntactic noise, the code is crystal
clear.

So instead of losing many potential users by focusing on a
niche market (unhappy C++ programmers), D should focus on its
major strengths, which already now make it stand high above
its competition.

Agrees with that. The problem with a language trying to scope
away a specific group of developers, from a existing ecosystem
is that your fighting the entire ecosystem, not just the
language. That is a mistake that many new languages make.

Why switch over from C++ to D?

Language => Sure.
Tooling => No.
Libraries => No.
Editors => No.
...

That has been the dilemma that not only D has faced. Until you
get critical mass where people start writing a massive amount
of your ecosystem, its hard to get people to switch over.

For instance, all these programmer-friendly features make D
even more convenient for scripting than scripting languages
themselves.

True but the same can be said about Go. And Go is even more
friendly and has the ecosystem now. You want to write something
more exotic. There is big change that somebody wrote a
module/package in Go. That is not going on with D. Sure, you
can take a existing c library and transform it into D but it
still takes work and is not always 100% idiomatic D.

That is the main difference between D and lets say Kotlin.
Kotlin build on top of Java and you can native imports all the
libraries. There is less effort involved.

Maybe this was mentioned before but a lot of programmers prefer
to lazy program. They want to write there code, move forward
with there project and not spend time on trying to get "things"
to import/convert/work. D has more people who have no issue
doing things the "hard" way. I applaud that resolve, i really
do. But at the same time its a barrier, a attitude that makes
it hard to accept those lazy people like me :)

IMHO, trying to compete directly with C++, C# and Java, with
the current state of the language and of its ecosystem, is
simply choosing the hardest path to success...

See above. Some people prefer the hard way. The masochists
*haha*. I know the angle where your coming from Ecstatic but
its hard to convince people. Especially when there is a
manpower shortage.

Frankly, i think the best way to go about moving D to
popularity, is simply money. More fully time programmers but
that requires money.

I do not understand why D does not have a BountySource account
( salt.bountysource.com ).

Look at nim ( $1,896 last month ) /crystal ($2,345 this month
):

They publish there fund raising. They motivate people by
pointing out the backers. Their income is a extra full time
developer ( who wants to work for cheap :) ). The whole D
foundation is nice and well but to me it feels like cloak and
daggers. It something hiding in the background, something
obscure. Maybe i am not expressing myself good again but D its
fund raising seems to be largely corporate focused but they
seem to lose a big market potential. Corporate funding is
harder to get then a lot of small donations.

Its just my two cents but if D wants to grow, it needs full
time developers. Not just volunteer work. People who can do the
grunt work that volunteers do not want to do ( because its just
not sexy ).

I agree with all that you said.

Just about Go, I must say that language is a bit rude, and
actually less convenient and versatile than D.

Many convenient features are missing (true reference classes,
member function polymorphism, generics, etc).

IMHO, Go is lagging somewhere between C and D.

Kotlin is a better contender, especially with is LLVM
implementation.

And with its current ecosystem, I'm sorry to say that indeed
Kotlin native is becoming de factor the best alternative to D.

Jun 24
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote:
I'm assuming that D is for general purpose programming as
well.

That seems to be where it is heading.  I don't think D stands
a chance in that domain, but we'll see.

With all due respect, on the contrary I think that promoting D
as a general purpose programming language could be its only
chance to really improve its popularity, and thus significantly
grow its current user base.

Most programming languages are technically "general purpose", but
when projects look for tooling they aren't looking for something
generic, they are looking for a solution to a specific domain.

So, for a language to succeed you need to provide the best
solution to something specific.

Jun 24
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2017-06-24 at 10:34 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-
d wrote:
=20

[=E2=80=A6]
Most programming languages are technically "general purpose", but=20
when projects look for tooling they aren't looking for something=20
generic, they are looking for a solution to a specific domain.
=20
So, for a language to succeed you need to provide the best=20
solution to something specific.

Just at the moment, for me, the reason to use D is it is the best
language for GTK+3 and GStreamer. For this I am prepared to deal with
the poor developer experience. For other tasks I'd use Go, Kotlin,
Groovy, even Rust because they have far better tooling on Linux.

If Kotlin Native gets an equivalent to GtkD, with Kotlin style GTK+3
and GStreamer bindings as opposed to the C use currently supported, It
is going to be a strong candidate for switching away from D to Kotlin.

--=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=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Jun 24
Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Saturday, 24 June 2017 at 10:34:07 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder wrote:
I'm assuming that D is for general purpose programming as
well.

That seems to be where it is heading.  I don't think D stands
a chance in that domain, but we'll see.

With all due respect, on the contrary I think that promoting D
as a general purpose programming language could be its only
chance to really improve its popularity, and thus
significantly grow its current user base.

Most programming languages are technically "general purpose",
but when projects look for tooling they aren't looking for
something generic, they are looking for a solution to a
specific domain.

So, for a language to succeed you need to provide the best
solution to something specific.

I agree, but it will be hard for D to beat C++, because people
who *need* to use C++ as a "systems programming language" won't
use D for the same reasons they don't use C#, Java or Go.

Just its GC keeps many C++ developers away from it, whether is
justified or not, despite D is as low level and performant.

But a GC is rarely a problem for a scripter, because most
scripting language already work this way.

So I think promoting D as a "systems programming language" won't
help in improving its popularity, as its GC doesn't make it the
best solution on this market.

Jun 24
Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Saturday, 24 June 2017 at 11:18:10 UTC, Ecstatic Coder wrote:
On Saturday, 24 June 2017 at 10:34:07 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 24 June 2017 at 09:35:56 UTC, Ecstatic Coder
wrote:
I'm assuming that D is for general purpose programming as
well.

That seems to be where it is heading.  I don't think D
stands a chance in that domain, but we'll see.

With all due respect, on the contrary I think that promoting
D as a general purpose programming language could be its only
chance to really improve its popularity, and thus
significantly grow its current user base.

I know that in certain other sectors, people have high
expectations of growth, but I really am at a loss to know what it
is that people might expect significant growth to be when we
already have some pretty impressive developments in the numbers
that we do have.

Daily unique dmd downloads in Jan 2013 were 150-200 much of the
time.  This year they have been between 1200 and 1700.  What kind
of growth would it take for you to be satisfied - I am curious?
Bearing in mind that the availability of all three compilers via
distributions has been improving over time.

And it seems to be unlikely to be a mere artefact of some sort
because it lines up with what one observes in the forums, in what
one hears about dconf lately versus prior years (I only went to
the past couple) and more importantly in development activity -
commercial and organic.

Weka.io hadn't even heard of D about three years ago and now they
have one of the largest D projects there is.  3.5 years ago me
neither - and soon I will be paying for about 4.5 full time
equivalent people to work on D (maybe a bit more than that in
time).  This little web company called eBay seems to be using it
- never heard of them before, but they seem pretty smart.  Remedy
Games released Quantum Leap, which I guess sold millions of
copies - it used D for scripting and they will be using D much
more throughout the firm shortly.  It's used by a $20+bn hedge fund for their trading systems, and will gain greater adoption within a$3.5bn hedge fund quite soon.

https://dlang.org/orgs-using-d.html

And somebody else remarked to me: "just look at code.dlang.org
these days - some interesting libraries and I don't know even
half the names that wrote them".

D doesn't need to persuade most C++ users to switch over to
succeed.  It doesn't need to persuade anyone you know to succeed.
It's at a stage where it's easy to keep growing without anything
particularly dramatic happening.  All it needs to do is appeal
just that little bit more to people who are already minded to use
D, or for whom people who are in pain and looking for an answer
(which D might be in part) to find out about the language - as
happened recently with Weka.  And if I compare the documentation,
libraries, and general quality of things today compared to 2014
when I started looking at the language, it's improving much
faster than just a little bit every year.  One doesn't notice
such change necessarily quickly.

I agree, but it will be hard for D to beat C++, because people
who *need* to use C++ as a "systems programming language" won't
use D for the same reasons they don't use C#, Java or Go.

Finance is still one of the larger spenders as an industry.  C++
is used quite broadly within it for analytics.  Not because
people want a system language and need to use malloc and free and
freely drop down to assembly, but because there isn't an adequate
alternative that's widely known about for now.  In 3-5 years
time, I think number of users in finance of D will be higher,
because it's the solution to pain.  Also, people tend to have
end-users working in many different languages.  Writing separate
clients for each one isn't ideal, and wrapping automatically
makes much more sense.  SWIG works, after a fashion, but D offers
some more pleasant and more maintainable alternatives.  R is done
(thanks bachmeier); Python is done (PyD); Excel is done (me,
Stefan + Atila); C/C++ is easy enough; C# will be done shortly,
and I have already done some work on Java.  If you say that
finance guys will never consider adopting D, I beg to differ
because I think I know that world quite well.  And that's just a
world I am familiar with, and there are plenty of others.

The web guys get the attention because they are doing interesting
things, have particular challenges, and can afford to talk -
because their edge doesn't mostly come from code, which is why
they open-source so much of it.  It's a mistake to think that the
people who talk are a good representation of the total number of
lines of code that are written each year, let alone the total
code that exists.  Visual Basic for Applications (Excel)
programmers for example do not tend to get much attention - yet
there's still a lot of code in VBA, a lot of new code being
written each year.  And it's not an ideal language.  Spreadsheets
themselves are a kind of functional code too.  And there are many
other languages used from which D can pick up market share
without anyone noticing.

Extended Pascal doesn't come up much.  But there's a 500k SLOC
codebase used to design great big ships and I was speaking to a
chap who spoke at dconf (Bastiaat) about his work on and use of
Pegged, and there's a decent chance that will be ported to D.
It's D or Ada - I never hear anyone talk about D vs Pascal and D
vs Ada.  But that would be a big and important project over time.

The truth of it as I see it is that the opinions of most
technical people are first order irrelevant for the adoption of
simply are not in a position to make decisions.  So the people
that matter are those who can make decisions, and of those it is
principals that matter and not agents - people who have the
authority to decide without having to consider primarily social
factors, and not managers who are primarily responsible to other
people and have to not just make the right decision, but justify
it.  And in fact that's my understanding of how D was frequently
adopted in the firms where it is used.  Liran at Weka didn't do a
bureaucratic study of the alternatives to justify his case to the
board.  He knew his problem domain, and what was important, and
when he heard about D from Kent Beck he recognised a solution,
and he had earned the authority to decide because of his past
accomplishments and it's difficult building a startup, but I
doubt having to justify his language choices is one of the main
things he worries about in life.  The Sociomantic founders didn't
have to persuade anyone in the beginning, and I guess when they
got bought Dunhumby didn't make their language choices a sticking
point but were probably more happy to have found such talented
people - if the purchase price is anything to go by.

When you have a small market share - and D's is not tiny, but
it's not a top 10 language either, you don't need to achieve mass
conversion to keep growing.  Just appeal to a slightly broader
set of people, or have a higher appeal to those that already are
sympathetic to the language - that's not something difficult to
achieve once the ball is rolling.

These ideas are all fairly standard.  I don't completely agree
with it, but Geoffrey Moore's Crossing the Chasm books etc get
the idea across well.  And the idea is actually much older - it
dates back to Toynbee's idea of creative minorities (new things
come from the fringes), to the ideas about Ibn Khaldun (the
founder of economics, one might say) about civilisational
renewal, and the same insight is in Ecclesiastes in the Bible (if
you think it through carefully).

Just its GC keeps many C++ developers away from it, whether is
justified or not, despite D is as low level and performant.

Yes - but read the Reddit comments this year.  There's a subtle
change in tone that's quite important.  Over the years people
have developed a standard set of excuses not to explore the
language - as Andrei observes, people develop these as a defence
in the face of a rapid rate of change.  If one looked into
everything, there'd be no time to do any work at all.

These standard sales objections are receding because they simply
don't hold water at all, or not nearly so.  There are no jobs in
D - well, if you are good I'm always open to working with the
right sort of people; and I was at DConf on a large table of
people all working for a living with D, and it was a funny line
because there are jobs in D, and for some people it's been pretty
good career-wise.  The blog posts on the GC have been very good
dismissal too.  (And I guess when we have ref-counted exceptions
and much more of Phobos is truly no-gc that will help too).  By
the way, the fact that people are committing their energy to work
on blog posts and so on tells you something about the increasing
commitment of energy from the community.

There's a C++ guy I work with now, and I was wondering what his
response might be to suggesting we consider using D in the part
of the business he is involved in.  He wasn't particularly
concerned about the GC, but I showed him that it didn't matter
for what we do, and that in any case you can avoid using it for
much and keep the heap small.  That wasn't the obstacle.  Main
thing is just needing to change our build process, which isn't
hard but will take a little bit of time.  He didn't need
readable, more componentised code and it  also - with a bit more
investment upfront - solves our wrapping problem.

People have very different contexts, and it's worth bearing that
in mind when one reads forum comments too.  Somebody who earns a
living teaching people popular languages but has invested lots of
time in D and hasn't found it paid off commercially - yes, of
course that will shape their attitude towards D from here.  But
that hasn't got to do much with the prospects for the further
development of the language, which isn't to say one can't learn
from them about what to improve.  Another guy who loves talking
about languages in a very theoretical way - but there's some
debate about whether he has written anything serious in D at all.
Well everyone is welcome to an opinion, but probably some
perspectives may be a better guide to the likelihood of broader
adoption than others.  Walter himself -
a man who not just survived but flourished in a very competitive
field operating as a leanly-staffed underdog - has remarked that
in his experience non-customers would tell you all kinds of
things, but when you satisfied what they wanted it never actually
lead to a change.  What works is paying attention to people who
are already customers, or at least using your product in some way
seriously.

And enterprise users generally don't have time to post much in
forums because they have work to do - how often do you see people
from Weka and Sociomantic post here in relation to the number of
people they have?

The above about listening to your real users could be seen as
self-serving, but I don't mean it in that way - I find the
leadership perfectly responsive as a commercial user (and I don't
really need much).  Rather it's just to observe there's a lot of
"what D really needs is this", but I'm not sure these
perspectives are always a good guide to what will help.

Wulfklaue:
"Agrees with that. The problem with a language trying to scope
away a specific group of developers, from a existing ecosystem is
that your fighting the entire ecosystem, not just the language.
That is a mistake that many new languages make."

Nobody in their right minds would try to target an
abstractly-defined category of developers.  The world doesn't
work that way, and it's not what anyone is doing.  People are
drawn to things that offer them something better, and what's
better very much depends in the situation you are in, and what
your constraints are - and situations that might appear identical
from the outside really aren't from the inside because these
things are shaped by culture, history, perceptions and emotional
factors within the group, not to mention different basic
conditions (industry and firm challenges, the kinds of people you

"Maybe this was mentioned before but a lot of programmers prefer
to lazy program. They want to write there code, move forward with
there project and not spend time on trying to get "things" to
import/convert/work. D has more people who have no issue doing
things the "hard" way. I applaud that resolve, i really do. But
at the same time its a barrier, a attitude that makes it hard to
accept those lazy people like me :)"

I don't know if D is a language for everybody.  I agree that D
has people who don't mind a bit of discomfort and doing things
the hard way.  I wouldn't be here if it were any different.  I
agree that it's a barrier, but complex living things can't grow
without a barrier, membrane or border.  I live in Barnes, and
it's in London, only 40 minutes to Mayfair, but like a little
English village.  And the reason for that is there is no tube and
it's a bit difficult to get here.  If there were a tube station
its character would be very different.  And that's true of all
social groups - if there is no price to be paid for admission,
implicit or not, then the group won't develop a character of its
own.  So I see the features of D that concern you as a positive -
it's a nice filter to be able to find the people that I would
like to work with.  My industry is a tough and demanding industry
and the people who do best in it are those who are resourceful
and able to figure things out for themselves when needed.  It's
not difficult to find excellent D programmers - one has to go
through many more candidates to find excellent C# programmers
that are aware of developments beyond the MS micro-culture.

A chap called Nassim Taleb talks about some of these ideas in his
work on hormesis and antifragility.  The D community creates
hormesis and this is a healthy filter.  And not being as
dependent on pretty labour-saving tools (and not needing them)
has some positive effects too.  Taleb talks about seeing a
businessman in the lobby, giving his bags to a porter to take up
to his room.  Twenty minutes later he sees him in the gym lifting
weights.  And his point is that taking advantage of natural
organic challenges to build fitness can build much more strength
than synthetic approaches to try to replace what we have lost.
I've personally benefited from having to figure many more things
out for myself than I would have needed to had I stuck with
Python or learnt C#.  The extra time invested wasn't significant
compared to the payoff even so far, but building a capability is
a gift that keeps on giving.

I wanted to contribute a small token amount to BountySource as I
thought I should.  You mention crystal at $2.3k/month. Well I've contributed much more than that personally per month on average in the time I have been involved in the community for things that I have open-sourced. Not the same thing as bounties, but for example the work we did on dub came out of my own pocket. And I'm sure Weka's investment to date dwarfs my modest contribution, and we have all benefited from it. In other words this language community works differently - I think commercial users would often rather approach someone directly than post a bounty. And as Adam says, the kind of people that work on D aren't necessarily motivated by money to do such work. Studies suggest that when you pay someone to do something it often takes the joy out of it by turning motivation from autotelic to instrumental. So it's not clear that it's even healthy for the community. Pragmatically, maybe it's one solution to get people to work on tedious but important things - but I really wouldn't consider it likely to be the main driver of developments for a community such as the one we have. It's happened to me by the way that I've asked somebody who contributes a lot to the community if he would be interested in helping me for a fee, and he really wasn't. And that's sometimes because people are very good programmers, and for some that can lead to pretty good career or business success and they contribute to D because they like it. It's a fortunate position for such a community to have such people working on the language or ecosystem that couldn't be paid by a company to do the same because their price is too high - provided any one person isn't ultra critical. "The whole D foundation is nice and well but to me it feels like cloak and daggers. It something hiding in the background, something obscure. Maybe i am not expressing myself good again but D its fund raising seems to be largely corporate focused but they seem to lose a big market potential. Corporate funding is harder to get then a lot of small donations." Give it a chance - it's barely got off the ground yet. Best way to get a foundation to listen to you is to give them a little bit of money if you can afford it, or do something helpful for them if you have time and some talent but not money to spare. I think corporate funding is easier to get than lots of small donations, because not all corporates are vast enterprises - it's by far easier to persuade entrepreneurial people who want to support something anyway then a legion of smaller supporters. Nonetheless the language needs both. Do you contribute yet? " Syntax is more about preference." If you look at the reactions of people around the world, beauty isn't something utterly idiosyncratically subjective - tastes vary, but less than some would say. And tastes may differ about language design (some might say part of that is that some people have better taste than others, but let's not discuss that for now) too. But in my experience idiomatic D code is very readable and clear, and if you compare it say to Boost or quite a lot of Python code that isn't always the case. And readability and clarity and ability to express intent matter a lot because code is read much more than it is written and code lives a long time. So it's not simply a question of preference - it's much more important than that. "Electronic wire transfer or bank check *bwahaaha*. What are we: 1980? Even worse, "Wire transfer information will be announced soon.". How long as that text been there??? Does the D team even look at there own website???" I paid via PayPal. It was easy. If you have a suggestion for improving, I am sure people would welcome a pull request. If you're not willing to do the work, then that's quite reasonable, but it's less reasonable to insist on others doing it... "I was under the impression that D with a bountysource account was going to be able to raise monthly funds on a higher level then Crystal and Nim. I really do not know what to say. No wonder when most new people do not even know its exists and the lack of acknowledgment on the website only reinforces this."$24k a year is a completely trivial amount that means nothing in
the scheme of things, and it's a mistake to be distracted by such
noise.

"There is no focus on raising funds."
Raising more substantial amounts of money works very differently
from raising the sorts of sums you discuss.  It makes sense given
where D starts, the people involved, and the fact that it's quite
return on time and attention is much higher (and it's working in
a domain that's easier to understand).

"Its easy to see why Nim and Crystal out fund D on bountysource."

If you have commercial users who have been using your language at
a reasonable scale in production (Weka manage 100s of Petabytes
using D, I think, and most people know the scale of Sociomantic's
use too) then your approach is going to be different from
strategy depends on where you are, but that's something that may
not be obvious to a newcomer or someone who hasn't had to think

https://news.ycombinator.com/item?id=14431315
Xored, and who else?
https://dlang.org/orgs-using-d.html
There are others not listed here even

Of course it's always interesting to hear ideas for improvement.

Laeeth

Jun 24
bachmeier <no spam.net> writes:
On Saturday, 24 June 2017 at 17:43:36 UTC, Laeeth Isharc wrote:
R is done (thanks bachmeier)

Integration with R is largely complete, but the missing piece has
always been lack of Windows support, which meant it wasn't an
option for most users.

Just this morning I got things working on Windows. Now that all
three major platforms have support, it is as reasonable to create
an R package with D functions as C, C++ or Fortran. Anyone can
write up a library of D functions and put a package on Bitbucket
or Github. The R user doesn't even need to know which language
the functions are written in.

This could possibly lead to wider adoption of D. Right now Rcpp
is the most popular dependency for R packages (over 1000 at last
check). And that's only a tiny fraction of overall Rcpp usage;
many users write their own C++ code but don't upload a package to
CRAN. It is my belief that these statisticians and
econometricians and biologists - few of whom have a C++
background or know what a GC is - are open to a language like D.
I plan to write a post on my website demonstrating usage soon.

On my agenda next are interoperability with Julia and Octave
(which isn't that popular, but would make a lot of Matlab code
available inside D). I honestly don't know if this will bring in
new D users, but for the most part I don't care, because I'm
doing it for my own research. Nonetheless, I think the potential
to expand the D userbase is there.

Jun 24
jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 24 June 2017 at 19:17:24 UTC, bachmeier wrote:
Just this morning I got things working on Windows. Now that all
three major platforms have support, it is as reasonable to
create an R package with D functions as C, C++ or Fortran.
Anyone can write up a library of D functions and put a package
on Bitbucket or Github. The R user doesn't even need to know
which language the functions are written in.

Music to my ears! Please put something up on announce when you
release it.

On my agenda next are interoperability with Julia and Octave
(which isn't that popular, but would make a lot of Matlab code
available inside D). I honestly don't know if this will bring
in new D users, but for the most part I don't care, because I'm
doing it for my own research. Nonetheless, I think the
potential to expand the D userbase is there.

I write less Matlab code these days than I used to, but I'm sure
that would be valuable as well. There's a lot of Matlab code out
there.

Jun 24
Igor <stojkovic.igor gmail.com> writes:
Maybe I am wrong but I get a feeling from posts in this thread
that some people are greatly underestimating the size of some
segments, like mentioning niche C++ programmers and only 0.01%
percent of developers needing memory management. The games
industry is growing like crazy [1][2] and after all these years
C++ is still the main language for that except that today 99% of
how D adoption would jump if someone created something on par
with Unity or Unreal engine, or even Cocos engine in D. And I
think D is already up to that task, with biggest pain points
being only cross platform support, especially for Android and iOS.

Also regarding the question whether D should be marketed as
general purpose or some special purpose language I find this
article [3] has it explained nicely, except that it seems to me
language should be marketed as general but have strong libraries
(or game engines) for specific purposes through which it should
market itself as something specialized.

[1]
http://kotaku.com/nearly-40-of-all-steam-games-were-released-in-2016-1789535450
[2]
http://www.gamasutra.com/view/news/267645/Over_500_games_now_submitted_to_iOS_App_Store_every_day.php
[3]
https://simpleprogrammer.com/2017/06/19/generalists-specialists/

Jun 25
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 25 June 2017 at 10:50:17 UTC, Igor wrote:
percent of developers needing memory management. The games
industry is growing like crazy [1][2] and after all these years
C++ is still the main language for that except that today 99%

I think the number of games are increasing because people now can
write games in other languages than C++. Unfortunately it is my
impression many of those games are the same game-engine being
redressed with differently themed graphics + some tweaks.

article [3] has it explained nicely, except that it seems to me
language should be marketed as general but have strong
libraries (or game engines) for specific purposes through which
it should market itself as something specialized.

But you need a focus, figure out what you are good at and go with
it. For which domain is your language the best option?

Decent doesn

Jun 25
Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 26 June 2017 at 06:47:53 UTC, Ola Fosheim Grøstad
wrote:
But you need a focus, figure out what you are good at and go
with it. For which domain is your language the best option?

Decent doesn

(Hit tab by mistake, why would tab+space be a sensible key
sequence for sending a message? Have experienced the same issue
in gmail.)

Anyway,  decent doesn't cut it, you have to focus on the areas
where your language can become the hands down best option.

Which is why throwing in some libraries for various domains won't
work. If you don't have good integration with one of the best
physics engines, then you can't really compete in the area of
games in the general case.

C++, Rust, Swift and Go have some very clear areas where they are
the best option if you evaluate the available options based on
your project's requirement spec. Which is why they have traction.

It isn't really a question of individual language features or
libraries making things possible. Those things attract individual
programmers, but it doesn't directly affect the cost/feasibility
analysis for a project where you evaluate options for something
very specific.

Scripting-like programming is different, there you often want one
flexible language that can do a little of everything, but it
doesn't have to master any particular area or do it particularly
well. E.g. Python.

Jun 26
bachmeier <no spam.net> writes:
On Saturday, 24 June 2017 at 23:05:58 UTC, jmh530 wrote:
On Saturday, 24 June 2017 at 19:17:24 UTC, bachmeier wrote:
Just this morning I got things working on Windows. Now that
all three major platforms have support, it is as reasonable to
create an R package with D functions as C, C++ or Fortran.
Anyone can write up a library of D functions and put a package
on Bitbucket or Github. The R user doesn't even need to know
which language the functions are written in.

Music to my ears! Please put something up on announce when you
release it.

It will probably take a while to put together a formal release.
In the meantime, you can test it if you want. Here's an example
that works for me on 64-bit Windows (it's obviously not the only
way to do this).

1. Create the D file with the functions you want to call from R.
Save this in librtest.d:

import embedr.r;
mixin(createRLibrary("rtest"));

import std.math;

export extern(C) {
Robj transform(Robj rx) {
auto x = RVector(rx);
double[] y = [log(x[0]), log(x[1])];
double result = y[0] + y[1];
return result.robj;
}
}

https://bitbucket.org/bachmeil/embedr/raw/89797bc39030a8433839119cfcdf7de6e8d7007c/inst/embedr/r.d

3. Windows requires R.lib for compilation, so I created that by
installing the MinGW pexports.exe utility.

C:\MinGW\bin\pexports.exe R.dll > R.def

Then create the .lib using Visual Studio:

"C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\lib.exe" /def:R.def /out:R.lib /machine:x64

4. Create librtest.dll using LDC:

"C:\Users\lance\ldc64\ldc2-1.3.0-beta2-win64-msvc\bin\ldmd2.exe"
-shared -m64 librtest.d r.d -version=inline R.lib

5. Open 64-bit R, load the library, and test it out:

.Call("transform", c(2.0, 3.0))

Disclaimer: I don't know much about Windows development. It would
be nice to have others test this out and identify problems. I
would like to figure out how to make R packages with D code on
Windows before doing a release.

Jun 25
jmh530 <john.michael.hall gmail.com> writes:
On Monday, 26 June 2017 at 01:31:43 UTC, bachmeier wrote:
[snip]
3. Windows requires R.lib for compilation, so I created that by
installing the MinGW pexports.exe utility.

C:\MinGW\bin\pexports.exe R.dll > R.def

You might make reference to cd to the folder that R.dll for x64
is in, for me it was
C:\Program Files\R\R-3.3.3\bin\x64

RTools hadn't installed pexports, so I installed a new MinGW.

Then create the .lib using Visual Studio:

"C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\lib.exe" /def:R.def /out:R.lib /machine:x64

I have Visual Studio 2017 installed, so I used
"C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x64\lib.exe"
/def:R.def /out:R.lib /machine:x64

but got the error

code: 126)

So I tried to use my Visual Studio 12 (did not have 14
installed). That seemed to work.

4. Create librtest.dll using LDC:

"C:\Users\lance\ldc64\ldc2-1.3.0-beta2-win64-msvc\bin\ldmd2.exe" -shared -m64
librtest.d r.d -version=inline R.lib

ldc2-1.3.0-beta1. Also, first you need to cd back to the original
location.

Then, this caused a problem because it used my 2017 Visual Studio
instead of the Visual Studio 12.0. So I gave up, for now, at this
point.

I might make another effort on this after work if I have time.

Jun 26
bachmeier <no spam.net> writes:
On Monday, 26 June 2017 at 12:20:02 UTC, jmh530 wrote:

[...]

Then, this caused a problem because it used my 2017 Visual
Studio instead of the Visual Studio 12.0. So I gave up, for
now, at this point.

I might make another effort on this after work if I have time.

Thanks for giving it a try. I have a feeling that this is a job
for Dub, SCons, or more likely, an R package that figures out
this stuff. Windows development seems to have more moving parts.
An R package on Linux requires adding a Makefile with one line.

Jun 26
jmh530 <john.michael.hall gmail.com> writes:
On Monday, 26 June 2017 at 13:10:17 UTC, bachmeier wrote:
Thanks for giving it a try. I have a feeling that this is a job
for Dub, SCons, or more likely, an R package that figures out
this stuff. Windows development seems to have more moving
parts. An R package on Linux requires adding a Makefile with
one line.

I don't know how well dub will handle it as my dub projects never
get this complicated. I haven't used SCons, but might make sense.
Reggae is another choice (though I haven't used that either).

Jun 26
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2017-06-26 at 16:30 +0000, jmh530 via Digitalmars-d wrote:
=20

[=E2=80=A6]
I don't know how well dub will handle it as my dub projects never=C2=A0
get this complicated. I haven't used SCons, but might make sense.=C2=A0
Reggae is another choice (though I haven't used that either).

Although I have been quite involved with SCons for a while, I am not
sure it is the future of build. Systems such as Meson/Ninja are much
nicer to work with.  Reggae is very much in the same camp as Meson. The
difference is that Meson has a big community giving it traction.
=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=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Jun 26
bachmeier <no spam.net> writes:
On Monday, 26 June 2017 at 12:20:02 UTC, jmh530 wrote:

[...]
I might make another effort on this after work if I have time.

I think this will be fairly easily handled within the embedr R
package. I should be able to put R.lib inside the package. R
knows where to find R.dll. The only thing that remains is to find
the LDC installation. I don't know how to automate that, but the
user could give the path as input.

I'll post here after updating and testing the embedr package.

Jun 26
jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote:
I'll post here after updating and testing the embedr package.

Great. I'll give it a go again when it's ready.

Jun 26
bachmeier <no spam.net> writes:
On Tuesday, 27 June 2017 at 02:40:37 UTC, jmh530 wrote:
On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote:
I'll post here after updating and testing the embedr package.

Great. I'll give it a go again when it's ready.

You can try this:
https://bitbucket.org/bachmeil/embedrwin

It's not in any sense a release. This is for early testing and
everything will be added to embedr in the future. It works for
me, so hopefully it will work for you.

Jun 27
bachmeier <no spam.net> writes:
On Tuesday, 27 June 2017 at 02:40:37 UTC, jmh530 wrote:
On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote:
I'll post here after updating and testing the embedr package.

Great. I'll give it a go again when it's ready.

An update. It looks like I will be able to get all of my research
programs to work on Windows. It might be easier to use D in R
packages on Windows than to use C/C++/Fortran because there is no
need to mess with R tools, which many end users find confusing.
The final piece of the puzzle would be an LDC installer for
Windows that puts it in the path. Then it would definitely be
easier to use D than C/C++/Fortran.

Jun 30
jmh530 <john.michael.hall gmail.com> writes:
On Friday, 30 June 2017 at 20:36:47 UTC, bachmeier wrote:
An update. It looks like I will be able to get all of my
research programs to work on Windows. It might be easier to use
D in R packages on Windows than to use C/C++/Fortran because
there is no need to mess with R tools, which many end users
find confusing. The final piece of the puzzle would be an LDC
installer for Windows that puts it in the path. Then it would
definitely be easier to use D than C/C++/Fortran.

Cool. I still need to give embedrwin a try...

Jul 02
jmh530 <john.michael.hall gmail.com> writes:
On Friday, 30 June 2017 at 20:36:47 UTC, bachmeier wrote:
On Tuesday, 27 June 2017 at 02:40:37 UTC, jmh530 wrote:
On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote:
I'll post here after updating and testing the embedr package.

Great. I'll give it a go again when it's ready.

An update. It looks like I will be able to get all of my
research programs to work on Windows. It might be easier to use
D in R packages on Windows than to use C/C++/Fortran because
there is no need to mess with R tools, which many end users
find confusing. The final piece of the puzzle would be an LDC
installer for Windows that puts it in the path. Then it would
definitely be easier to use D than C/C++/Fortran.

I just gave it a try. Got an error. As far as I can tell, the
problem is that my user name has a space in it
(firstname[space]lastname).

library(embedrwin)
setwd("C:\\test\\")
compile("librtest",
"C:\\D\\ldc2\\ldc2-1.3.0-beta1-win64-msvc\\bin")

[1] "\"C:\\D\\ldc2\\ldc2-1.3.0-beta1-win64-msvc\\bin\\ldmd2.exe\"
-shared -m64 librtest.d
C:/Users/firstname[space]lastname/Documents/R/win-library/3.3/embed
win\\embedrwin\\r.d -version=inline R.lib"
[1] "Error: module firstname is in file 'C:\\Users\\firstname.d'
[2] "import path[0] =
C:\\D\\ldc2\\LDC2-1~1.0-B\\bin\\..\\import\\ldc"
[3] "import path[1] = C:\\D\\ldc2\\LDC2-1~1.0-B\\bin\\..\\import"
attr(,"status")
[1] 1
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared object 'C:/test/librtest.dll':
LoadLibrary failure:  The specified module could not be found.
1: In file.copy(paste0(loc, "/embedr/R.lib"), getwd()) :
problem copying
C:\Users\firstname[space]lastname\Documents\R\win-library\3.3\em
edrwin\embedr\R.lib to C:\test\R.lib: No such file or directory
2: running command
'"C:\D\ldc2\ldc2-1.3.0-beta1-win64-msvc\bin\ldmd2.exe" -shared
-m64 librtest.d
C:/Users/firstname[space]lastname/Documents/R/win-library/3.3/emb
drwin\embedrwin\r.d -version=inline R.lib' had status 1

Jul 03
bachmeier <no spam.net> writes:
On Tuesday, 4 July 2017 at 03:41:35 UTC, jmh530 wrote:

I just gave it a try. Got an error. As far as I can tell, the
problem is that my user name has a space in it
(firstname[space]lastname).

library(embedrwin)
setwd("C:\\test\\")
compile("librtest",
"C:\\D\\ldc2\\ldc2-1.3.0-beta1-win64-msvc\\bin")

[1]
"\"C:\\D\\ldc2\\ldc2-1.3.0-beta1-win64-msvc\\bin\\ldmd2.exe\"
-shared -m64 librtest.d
C:/Users/firstname[space]lastname/Documents/R/win-library/3.3/embed
win\\embedrwin\\r.d -version=inline R.lib"
[1] "Error: module firstname is in file
[2] "import path[0] =
C:\\D\\ldc2\\LDC2-1~1.0-B\\bin\\..\\import\\ldc"
[3] "import path[1] =
C:\\D\\ldc2\\LDC2-1~1.0-B\\bin\\..\\import"

Thanks. I forgot a pair of quotes.

It's probably better to file issues on Bitbucket or use Gitter[1]
if possible. Or send an email to me at the address here[2].
Someone will get upset with me for using this mailing list for my
package.

[1] https://gitter.im/dlang-embedr/Lobby
[2] http://www.k-state.edu/economics/staff/bios/bachmeier.html

Jul 04
Kagamin <spam here.lot> writes:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)

The memory footprint doesn't matter. Those times are OVER :-).

Do you want D to compete in enterprise domain? Of 16 programs
running on my machine 13 are native.

Jun 23
Joakim <dlang joakim.fea.st> writes:
On Friday, 23 June 2017 at 16:49:54 UTC, Kagamin wrote:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)

The memory footprint doesn't matter. Those times are OVER :-).

Do you want D to compete in enterprise domain? Of 16 programs
running on my machine 13 are native.

Not only that, but the majority of use of Java and soon Kotlin is
on Android, where efficiency and memory footprint matters a lot,
hence Java moving to AoT-compilation when Android 5.0 released
three years ago and adding a concurrent GC:

C# lost out internally at Microsoft precisely because of how
bloated it made everything, with signs that native is ascendant
again in recent years:

https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a

Bienlein may be right that there are niches where memory
footprint doesn't matter and there were years where it wasn't a
big deal, but it's back now.  RAM is really cheap today, but
latency and power efficiency are the big issues.  You could put 8
GBs of RAM in every smartphone right now, and there are some
models which do (http://www.gsmarena.com/oneplus_5-8647.php), but
the only reason most don't is because it'd suck a lot more power.

Jun 23
Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 23 June 2017 at 20:25:10 UTC, Joakim wrote:
On Friday, 23 June 2017 at 16:49:54 UTC, Kagamin wrote:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)

The memory footprint doesn't matter. Those times are OVER :-).

Do you want D to compete in enterprise domain? Of 16 programs
running on my machine 13 are native.

Not only that, but the majority of use of Java and soon Kotlin
is on Android, where efficiency and memory footprint matters a
lot, hence Java moving to AoT-compilation when Android 5.0
released three years ago and adding a concurrent GC:

C# lost out internally at Microsoft precisely because of how
bloated it made everything, with signs that native is ascendant
again in recent years:

https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a

Bienlein may be right that there are niches where memory
footprint doesn't matter and there were years where it wasn't a
big deal, but it's back now.  RAM is really cheap today, but
latency and power efficiency are the big issues.  You could put
8 GBs of RAM in every smartphone right now, and there are some
models which do (http://www.gsmarena.com/oneplus_5-8647.php),
but the only reason most don't is because it'd suck a lot more
power.

C# lost the Longhorn/Vista battle, but won the Windows 10 UWP one.

Try to find the C++ talks.

https://channel9.msdn.com/Events/Build/2017

Jun 23
Joakim <dlang joakim.fea.st> writes:
On Friday, 23 June 2017 at 22:35:04 UTC, Paulo Pinto wrote:
On Friday, 23 June 2017 at 20:25:10 UTC, Joakim wrote:
C# lost out internally at Microsoft precisely because of how
bloated it made everything, with signs that native is
ascendant again in recent years:

https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a

C# lost the Longhorn/Vista battle, but won the Windows 10 UWP
one.

I wouldn't say C# won, UWP is implemented in C++ and supports
C++.  Of course, UWP is so unpopular that they eventually allowed
Win32 apps into their store:

https://arstechnica.com/information-technology/2016/09/desktop-apps-make-their-way-into-the-windows-store/

Now they are so desparate for people to use it that they just
released a version of Windows that will only install UWP apps,
Windows 10 S:

https://arstechnica.com/information-technology/2017/05/microsoft-takes-on-chrome-os-with-new-windows-10-s/

Try to find the C++ talks.

https://channel9.msdn.com/Events/Build/2017

You seem to have missed the bit where I said C# lost
_internally_.  Their plan, as detailed in the Vista link, was to
move all their own apps to C#, which has yet to happen.  I hear
C# has been very successful for corporate LoB apps, which are
developed quickly and not used widely enough to spend much time
on optimizing for performance.

On Friday, 23 June 2017 at 22:38:29 UTC, Paulo Pinto wrote:
Looking forward to see blazing fast D applications on the
Windows store.

Why?  The Windows Store is a ghost town, with google not even
bothering to package Chrome on there, despite their browser being
the most installed and used app on Windows.

Jun 23
Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 22 June 2017 at 10:23:37 UTC, Russel Winder wrote:
On Thu, 2017-06-22 at 10:00 +0000, Paulo Pinto via
Digitalmars-d wrote:
[…]

They were all about Swift, Java, Kotlin, C#.

Isn't Swift a native code language?

Just like Java when one uses any commercial JDK or C# when
targeting UWP or Windows 8.x devices.

Jun 22
Wulfklaue <wulfklaue wulfklaue.com> writes:
On Monday, 19 June 2017 at 16:13:20 UTC, Russel Winder wrote:
I'd be more bothered by Kotlin native that Scala native.

Well, Kotlin/Native just came out with version 0.3. And it
includes Windows support. Take that Apple/Swift ;)

Its impressive how fast things are being developer by Jetbrain.

There first release ( 0.1 ) on 31 March 2017.
Then Coroutines ( 0.2 ) on 11 May 2017.
Now Windows support ( 0.3 ) on June 23 2017.

Jun 23
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2017-06-23 at 13:14 +0000, Wulfklaue via Digitalmars-d wrote:
On Monday, 19 June 2017 at 16:13:20 UTC, Russel Winder wrote:
I'd be more bothered by Kotlin native that Scala native.

=20
Well, Kotlin/Native just came out with version 0.3. And it=C2=A0
includes Windows support. Take that Apple/Swift ;)
=20
Its impressive how fast things are being developer by Jetbrain.
=20
There first release ( 0.1 ) on 31 March 2017.
Then Coroutines ( 0.2 ) on 11 May 2017.
Now Windows support ( 0.3 ) on June 23 2017.

I suspect this is a tribute to LLVM as well as the Kotlin Native team.
Like LDC takes DMD frontend and injects into the LLVM backend, so
Kotlin Native takes the Kotlin frontend and injects into LLVM.

Sadly they currently just use the GTK C API directly, rather than
having a Kotlin idiomatic binding. Not competition for D in the GTK
GStreamer arena just yet. I have however put in issues.

--=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=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Jun 23
Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote:
Go gets parallel compilation, at last, and better garbage
collection. The former is not a problem for D, but the latter…

<probably-a-troll-but-still-worth-saying-that-gc-can-change/>

Indeed a faster garbage collector will be a good selling point
for Go.

But Go still doesn't have proper generics, which keeps it
light-years behind D in terms of expressivity.

Still time to convince people to use D instead of Go then...

Jun 19
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2017-06-19 at 19:07 +0000, Ecstatic Coder via Digitalmars-d
wrote:
[=E2=80=A6]
=20
But Go still doesn't have proper generics, which keeps it=C2=A0
light-years behind D in terms of expressivity.

Go doesn't have, and likely will never have, generics in the C++, D,
Chapel sense, but then Rust doesn't either. Go has two routes for
achieving the goal that C++ generics (and hence D and Chapel generics)
were intended for. You have to use the idiomatic approach for the
language. Saying Go is behind D is missing the point that the languages
are different and have to be used differently to achieve the same goal.

Still time to convince people to use D instead of Go then...

The only way of doing this is to have lots of problems programmed
idiomatically in D, Go, Rust, Kotlin, with unbiased compare and
contrast notes. You end up finding different languages are best in
different problems. Which is hardly a surprise. Generally it is the
libraries that are the truly key factors.=20

And do not underestimate personal choice, different language gel with
different people (though there is some Stockholm Syndrome effect with
some people).

For me just now, D beats C++ for working with Gtk and GStreamer. For
other problems I go with Go, or partake of Python. C++17, or more
likely C++20, may make C++ interesting again. I though C++11 had, but
in the end it didn't.

--=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=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=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   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Jun 20