www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Go 1.9

reply 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 2017
next sibling parent 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 2017
prev sibling next sibling parent reply 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 2017
parent reply 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 2017
parent 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 2017
prev sibling next sibling parent reply 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 2017
next sibling parent 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 2017
prev sibling parent reply 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 2017
next sibling parent reply 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 2017
parent 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 2017
prev sibling next sibling parent reply 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 2017
next sibling parent reply 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 2017
parent 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.

https://www.quora.com/Why-is-Python-so-popular-despite-being-so-slow/answer/Laeeth-Isharc?share=5ebdf91a&srid=35gE

Acam paper linked at the end of this.
Jun 22 2017
prev sibling next sibling parent 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
always dreadfully disappointed how bad at programming the lower 50% of
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 2017
prev sibling parent reply 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.



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 2017
parent reply 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

=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 2017
next sibling parent reply 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:

 […]
 






Swift Apple, Java Oracle... so there is more focus on them 
naturally.


 Isn't Swift a native code language?


Yep ... Its it uses LLVM.


memory footprint to prove it :)



(C++ target) or Nim(C target) ).
Jun 22 2017
next sibling parent reply 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:

 […]
 






 Swift Apple, Java Oracle... so there is more focus on them 
 naturally.


 Isn't Swift a native code language?


 Yep ... Its it uses LLVM.


 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.


it isn't an optimizing compiler and only supports dynamic linking.


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.


static linking is used.

Better learn what the competition is actually doing.
Jun 22 2017
parent reply 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 
dynamic class loading? I know how JamaicaVM does it, no thanks.



 althouth it isn't an optimizing compiler and only supports 
 dynamic linking.


 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 2017
parent reply 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 
 dynamic class loading? I know how JamaicaVM does it, no thanks.


ExcelsiorJET is quite easy to figure out, you can download their 
open source version.

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



 althouth it isn't an optimizing compiler and only supports 
 dynamic linking.


 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.


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 
used instead.

Also .NET Native is still kind of work in progress, as they still 

toolchain. With every Windows 10 SDK release there are new 
improvement made to it.

In any case, even if native compilation toolchains for Java and 

you don't come up with a solid history to go against them, that 
make people actually curious to try out D.
Jun 23 2017
parent reply Araq <rumpf_a web.de> writes:
On Friday, 23 June 2017 at 20:13:15 UTC, Paulo Pinto wrote:

 ExcelsiorJET is quite easy to figure out, you can download 
 their open source version.


So in other words, you do not have used these products and only 
read their websites, got it.


 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 
 used instead.


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 

 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 

dependencies", whom are you kidding here.
Jun 23 2017
parent reply 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 

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

 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 2017
prev sibling parent reply Bienlein <jeti789 web.de> writes:

 memory footprint to prove it :)


The memory footprint doesn't matter. Those times are OVER :-).
Jun 22 2017
next sibling parent Bienlein <jeti789 web.de> writes:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:


 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 2017
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:


 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 2017
parent reply 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:


 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 2017
parent reply 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 2017
parent reply 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 2017
parent reply 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 2017
parent reply 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, 
everything is made so that the most obvious and readable code 
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.


current state of the language and of its ecosystem, is simply 
choosing the hardest path to success...
Jun 24 2017
next sibling parent reply 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, 
 everything is made so that the most obvious and readable code 
 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 :)



 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 2017
next sibling parent reply 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 2017
parent reply 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 ).

https://nim-lang.org/sponsors.html

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

https://crystal-lang.org/sponsors/

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 2017
next sibling parent 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 2017
prev sibling next sibling parent 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 
being a bad joke.)


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 2017
prev sibling parent reply 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 2017
parent 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 
something per download ). Now it already requires some searching 
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 2017
prev sibling parent 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, 
 everything is made so that the most obvious and readable code 
 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 :)



 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 2017
prev sibling parent reply 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 2017
next sibling parent 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 2017
prev sibling parent reply 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 


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 2017
parent reply 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.

http://erdani.com/d/downloads.daily.png

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 



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, 

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 
D, because even if they were fanatics about its adoption they 
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 
at getting people to think more carefully about this blanket 
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 
persuading - he could just recognise it as leading to more 
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 
have already), and so on.

"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 

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 

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 
a lean team, to start with more substantial amounts because the 
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 
languages that are newer and with less commercial adoption.  Your 
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 
about how to raise money.

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 2017
parent reply 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 2017
parent reply 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 2017
next sibling parent reply 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 
those developers have many bad things to say about it. Imagine 
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 2017
parent reply 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% 
 of those developers have many bad things to say about it.


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 2017
parent 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 2017
prev sibling parent reply 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;
   }
}

2. Download embedr to that same directory 
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:

dyn.load("librtest.dll")
.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 2017
parent reply 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

I also got access denied, so used administrative cmd.

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

LINK : fatal error LNK1171: unable to load mspdb140.dll (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


Path adjusted for my location of ldc2. Also, I had 
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 2017
next sibling parent reply 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 2017
parent reply 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 2017
parent 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 2017
prev sibling parent reply 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 2017
parent reply 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 2017
next sibling parent 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 2017
prev sibling parent reply 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 2017
next sibling parent 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 2017
prev sibling parent reply 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' 
which cannot be read"
[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.
In addition: Warning messages:
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 2017
parent 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 
 'C:\\Users\\firstname.d' which cannot be read"
 [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 2017
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:


 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 2017
parent reply 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:


 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:

https://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/3/#h2


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 2017
parent reply 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:


 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:

 https://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/3/#h2


 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.




Try to find the C++ talks.

https://channel9.msdn.com/Events/Build/2017
Jun 23 2017
parent 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:


 bloated it made everything, with signs that native is 
 ascendant again in recent years:

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



 one.



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



_internally_.  Their plan, as detailed in the Vista link, was to 


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 2017
prev sibling parent 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:

 […]
 

 


 Isn't Swift a native code language?



targeting UWP or Windows 8.x devices.
Jun 22 2017
prev sibling parent reply 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 2017
parent 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 2017
prev sibling parent reply 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 2017
parent 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 2017