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
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
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
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
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
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
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
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
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
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
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
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
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
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
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. They were all about Swift, Java, Kotlin, C#. There were hardly any meaningful talks with C or C++ content related to actual software development on their OSes, other than to share the latest improvements in compiler/IDE tooling and ANSI C++ compliance.
Jun 22
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
 They were all about Swift, Java, Kotlin, C#.
=20
Isn't Swift a native code language?
=20
--=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 22
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:
 […]
 
 They were all about Swift, Java, Kotlin, C#.
Those are also the major players in the market. C# Microsoft, Swift Apple, Java Oracle... so there is more focus on them naturally.
 Isn't Swift a native code language?
Yep ... Its it uses LLVM. Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) C# may change to a native compiled language with CoreRT ( This translates C# to C++ code and then compiles it. A bit like Haxe (C++ target) or Nim(C target) ).
Jun 22
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:
 […]
 
 They were all about Swift, Java, Kotlin, C#.
Those are also the major players in the market. C# Microsoft, Swift Apple, Java Oracle... so there is more focus on them naturally.
 Isn't Swift a native code language?
Yep ... Its it uses LLVM. Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :)
Java is AOT compiled to native code via Excelsior JET, IBM J9, IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART and eventually Java 10. Sun was the only one religilous against any kind of AOT support, all major commercial JDKs always supported AOT compilation. C# is AOT compiled to native code since day 1, via NGEN, althouth it isn't an optimizing compiler and only supports dynamic linking. C# and VB.NET for Windows 8 and Windows 8.1 only support AOT compilation to native code via a format called MDIL (Machine Dependent Intermediate Language), basically native code with symbolic labels, linked on the devices at installation time. C# and VB.NET for UWP are always AOT compiled to native code and static linking is used. Better learn what the competition is actually doing.
Jun 22
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.
 C# is AOT compiled to native code since day 1, via NGEN, 
 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.
Reflection and dynamic class loading are essential parts of C# and Java and do not work well with AOT compilation and never will. Money can't patch over design mistakes.
Jun 23
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.
 C# is AOT compiled to native code since day 1, via NGEN, 
 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.
Reflection and dynamic class loading are essential parts of C# 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 try to bring more features from System C# into regular .NET 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 C# aren't perfect, they make it less appealing to try out D if you don't come up with a solid history to go against them, that make people actually curious to try out D.
Jun 23
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 
 C# aren't perfect, they make it less appealing to try out D if 
 you don't come up with a solid history to go against them, that 
 make people actually curious to try out D.
That's just "I looked at the websites, never used these tools in practice but found them convincing" phrased differently to pretend you have an argument. The success of Go strongly indicates people generally don't connect Java/C# to "native code" or "slim binaries without dependencies", whom are you kidding here.
Jun 23
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 
 connect Java/C# to "native code" or "slim binaries without 
 dependencies", whom are you kidding here.
You are right, it was a mistake to come back to these forums, after the GDC announcement. Looking forward to see blazing fast D applications on the Windows store.
Jun 23
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 
 connect Java/C# to "native code" or "slim binaries without 
 dependencies", whom are you kidding here.
You are right, it was a mistake to come back to these forums, after the GDC announcement. Looking forward to see blazing fast D applications on the Windows store.
Just FYI, Araq is the author of Nim (https://nim-lang.org/), so I'm sure he didn't have any intention in making D look good ;) On the other hand, I think he made good technical arguments, (leaving aside his Ad Hominem way of expressing, which I think was out of place) which I think you should actually consider.
Jun 23
prev sibling parent reply Bienlein <jeti789 web.de> writes:
 Java, Kotlin, C# are still Jit compiled languages, with the 
 memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
Jun 22
next sibling parent Bienlein <jeti789 web.de> writes:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
 Java, Kotlin, C# are still Jit compiled languages, with the 
 memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
Here are some references: http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc There you can see how little memory Go uses compared to C and Java. Java will also get better as it will also get value types in some upcoming JDK.
Jun 22
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:
 Java, Kotlin, C# are still Jit compiled languages, with the 
 memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
People said that 30 years ago too... It is still an issue, though. Not as much as it was, but still relevant. Programmers seem to be able to suck up whatever RAM is available on the low-end by adding frameworks, bloated libraries and runtimes, or just bugs…
Jun 23
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:
 Java, Kotlin, C# are still Jit compiled languages, with the 
 memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
People said that 30 years ago too... It is still an issue, though. Not as much as it was, but still relevant. Programmers seem to be able to suck up whatever RAM is available on the low-end by adding frameworks, bloated libraries and runtimes, or just bugs…
I have not done any manual memory management at work for the last 25 years. Did some C++ programming at college and a bit at home where I had to take care of memory myself. That was it. Till I retire in 20 years I will also not have been doing any manual memory management. That kind of stuff only survives in very special areas where 0.1% of all software developers work. That being said let me repeat that D needs a decent GC for being able to create any traction, because those 99.9% of the share are the far bigger market.
Jun 23
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
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
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
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. IMHO, trying to compete directly with C++, C# and Java, with the current state of the language and of its ecosystem, is simply choosing the hardest path to success...
Jun 24
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 :)
 IMHO, trying to compete directly with C++, C# and Java, with 
 the current state of the language and of its ecosystem, is 
 simply choosing the hardest path to success...
See above. Some people prefer the hard way. The masochists *haha*. I know the angle where your coming from Ecstatic but its hard to convince people. Especially when there is a manpower shortage. Frankly, i think the best way to go about moving D to popularity, is simply money. More fully time programmers but that requires money. I do not understand why D does not have a BountySource account ( salt.bountysource.com ). Look at nim ( $1,896 last month ) /crystal ( $2,345 this month ): They publish there fund raising. They motivate people by pointing out the backers. Their income is a extra full time developer ( who wants to work for cheap :) ). The whole D foundation is nice and well but to me it feels like cloak and daggers. It something hiding in the background, something obscure. Maybe i am not expressing myself good again but D its fund raising seems to be largely corporate focused but they seem to lose a big market potential. Corporate funding is harder to get then a lot of small donations. Its just my two cents but if D wants to grow, it needs full time developers. Not just volunteer work. People who can do the grunt work that volunteers do not want to do ( because its just not sexy ).
Jun 24
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
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
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
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
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
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
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 :)
 IMHO, trying to compete directly with C++, C# and Java, with 
 the current state of the language and of its ecosystem, is 
 simply choosing the hardest path to success...
See above. Some people prefer the hard way. The masochists *haha*. I know the angle where your coming from Ecstatic but its hard to convince people. Especially when there is a manpower shortage. Frankly, i think the best way to go about moving D to popularity, is simply money. More fully time programmers but that requires money. I do not understand why D does not have a BountySource account ( salt.bountysource.com ). Look at nim ( $1,896 last month ) /crystal ( $2,345 this month ): They publish there fund raising. They motivate people by pointing out the backers. Their income is a extra full time developer ( who wants to work for cheap :) ). The whole D foundation is nice and well but to me it feels like cloak and daggers. It something hiding in the background, something obscure. Maybe i am not expressing myself good again but D its fund raising seems to be largely corporate focused but they seem to lose a big market potential. Corporate funding is harder to get then a lot of small donations. Its just my two cents but if D wants to grow, it needs full time developers. Not just volunteer work. People who can do the grunt work that volunteers do not want to do ( because its just not sexy ).
I agree with all that you said. Just about Go, I must say that language is a bit rude, and actually less convenient and versatile than D. Many convenient features are missing (true reference classes, member function polymorphism, generics, etc). IMHO, Go is lagging somewhere between C and D. Kotlin is a better contender, especially with is LLVM implementation. And with its current ecosystem, I'm sorry to say that indeed Kotlin native is becoming de factor the best alternative to D.
Jun 24
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
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
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 use D for the same reasons they don't use C#, Java or Go. Just its GC keeps many C++ developers away from it, whether is justified or not, despite D is as low level and performant. But a GC is rarely a problem for a scripter, because most scripting language already work this way. So I think promoting D as a "systems programming language" won't help in improving its popularity, as its GC doesn't make it the best solution on this market.
Jun 24
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 
 use D for the same reasons they don't use C#, Java or Go.
Finance is still one of the larger spenders as an industry. C++ is used quite broadly within it for analytics. Not because people want a system language and need to use malloc and free and freely drop down to assembly, but because there isn't an adequate alternative that's widely known about for now. In 3-5 years time, I think number of users in finance of D will be higher, because it's the solution to pain. Also, people tend to have end-users working in many different languages. Writing separate clients for each one isn't ideal, and wrapping automatically makes much more sense. SWIG works, after a fashion, but D offers some more pleasant and more maintainable alternatives. R is done (thanks bachmeier); Python is done (PyD); Excel is done (me, Stefan + Atila); C/C++ is easy enough; C# will be done shortly, and I have already done some work on Java. If you say that finance guys will never consider adopting D, I beg to differ because I think I know that world quite well. And that's just a world I am familiar with, and there are plenty of others. The web guys get the attention because they are doing interesting things, have particular challenges, and can afford to talk - because their edge doesn't mostly come from code, which is why they open-source so much of it. It's a mistake to think that the people who talk are a good representation of the total number of lines of code that are written each year, let alone the total code that exists. Visual Basic for Applications (Excel) programmers for example do not tend to get much attention - yet there's still a lot of code in VBA, a lot of new code being written each year. And it's not an ideal language. Spreadsheets themselves are a kind of functional code too. And there are many other languages used from which D can pick up market share without anyone noticing. Extended Pascal doesn't come up much. But there's a 500k SLOC codebase used to design great big ships and I was speaking to a chap who spoke at dconf (Bastiaat) about his work on and use of Pegged, and there's a decent chance that will be ported to D. It's D or Ada - I never hear anyone talk about D vs Pascal and D vs Ada. But that would be a big and important project over time. The truth of it as I see it is that the opinions of most technical people are first order irrelevant for the adoption of 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 through many more candidates to find excellent C# programmers that are aware of developments beyond the MS micro-culture. A chap called Nassim Taleb talks about some of these ideas in his work on hormesis and antifragility. The D community creates hormesis and this is a healthy filter. And not being as dependent on pretty labour-saving tools (and not needing them) has some positive effects too. Taleb talks about seeing a businessman in the lobby, giving his bags to a porter to take up to his room. Twenty minutes later he sees him in the gym lifting weights. And his point is that taking advantage of natural organic challenges to build fitness can build much more strength than synthetic approaches to try to replace what we have lost. I've personally benefited from having to figure many more things out for myself than I would have needed to had I stuck with Python or learnt C#. The extra time invested wasn't significant compared to the payoff even so far, but building a capability is a gift that keeps on giving. I wanted to contribute a small token amount to BountySource as I thought I should. You mention crystal at $2.3k/month. Well I've contributed much more than that personally per month on average in the time I have been involved in the community for things that I have open-sourced. Not the same thing as bounties, but for example the work we did on dub came out of my own pocket. And I'm sure Weka's investment to date dwarfs my modest contribution, and we have all benefited from it. In other words this language community works differently - I think commercial users would often rather approach someone directly than post a bounty. And as Adam says, the kind of people that work on D aren't necessarily motivated by money to do such work. Studies suggest that when you pay someone to do something it often takes the joy out of it by turning motivation from autotelic to instrumental. So it's not clear that it's even healthy for the community. Pragmatically, maybe it's one solution to get people to work on tedious but important things - but I really wouldn't consider it likely to be the main driver of developments for a community such as the one we have. It's happened to me by the way that I've asked somebody who contributes a lot to the community if he would be interested in helping me for a fee, and he really wasn't. And that's sometimes because people are very good programmers, and for some that can lead to pretty good career or business success and they contribute to D because they like it. It's a fortunate position for such a community to have such people working on the language or ecosystem that couldn't be paid by a company to do the same because their price is too high - provided any one person isn't ultra critical. "The whole D foundation is nice and well but to me it feels like cloak and daggers. It something hiding in the background, something obscure. Maybe i am not expressing myself good again but D its fund raising seems to be largely corporate focused but they seem to lose a big market potential. Corporate funding is harder to get then a lot of small donations." Give it a chance - it's barely got off the ground yet. Best way to get a foundation to listen to you is to give them a little bit of money if you can afford it, or do something helpful for them if you have time and some talent but not money to spare. I think corporate funding is easier to get than lots of small donations, because not all corporates are vast enterprises - it's by far easier to persuade entrepreneurial people who want to support something anyway then a legion of smaller supporters. Nonetheless the language needs both. Do you contribute yet? " Syntax is more about preference." If you look at the reactions of people around the world, beauty isn't something utterly idiosyncratically subjective - tastes vary, but less than some would say. And tastes may differ about language design (some might say part of that is that some people have better taste than others, but let's not discuss that for now) too. But in my experience idiomatic D code is very readable and clear, and if you compare it say to Boost or quite a lot of Python code that isn't always the case. And readability and clarity and ability to express intent matter a lot because code is read much more than it is written and code lives a long time. So it's not simply a question of preference - it's much more important than that. "Electronic wire transfer or bank check *bwahaaha*. What are we: 1980? Even worse, "Wire transfer information will be announced soon.". How long as that text been there??? Does the D team even look at there own website???" I paid via PayPal. It was easy. If you have a suggestion for improving, I am sure people would welcome a pull request. If you're not willing to do the work, then that's quite reasonable, but it's less reasonable to insist on others doing it... "I was under the impression that D with a bountysource account was going to be able to raise monthly funds on a higher level then Crystal and Nim. I really do not know what to say. No wonder when most new people do not even know its exists and the lack of acknowledgment on the website only reinforces this." $24k a year is a completely trivial amount that means nothing in the scheme of things, and it's a mistake to be distracted by such noise. "There is no focus on raising funds." Raising more substantial amounts of money works very differently from raising the sorts of sums you discuss. It makes sense given where D starts, the people involved, and the fact that it's quite 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
 Java, Kotlin, C# are still Jit compiled languages, with the 
 memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
Do you want D to compete in enterprise domain? Of 16 programs running on my machine 13 are native.
Jun 23
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:
 Java, Kotlin, C# are still Jit compiled languages, with the 
 memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
Do you want D to compete in enterprise domain? Of 16 programs running on my machine 13 are native.
Not only that, but the majority of use of Java and soon Kotlin is on Android, where efficiency and memory footprint matters a lot, hence Java moving to AoT-compilation when Android 5.0 released three years ago and adding a concurrent GC: https://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/3/#h2 C# lost out internally at Microsoft precisely because of how bloated it made everything, with signs that native is ascendant again in recent years: https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a Bienlein may be right that there are niches where memory footprint doesn't matter and there were years where it wasn't a big deal, but it's back now. RAM is really cheap today, but latency and power efficiency are the big issues. You could put 8 GBs of RAM in every smartphone right now, and there are some models which do (http://www.gsmarena.com/oneplus_5-8647.php), but the only reason most don't is because it'd suck a lot more power.
Jun 23
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:
 Java, Kotlin, C# are still Jit compiled languages, with the 
 memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
Do you want D to compete in enterprise domain? Of 16 programs running on my machine 13 are native.
Not only that, but the majority of use of Java and soon Kotlin is on Android, where efficiency and memory footprint matters a lot, hence Java moving to AoT-compilation when Android 5.0 released three years ago and adding a concurrent GC: https://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/3/#h2 C# lost out internally at Microsoft precisely because of how bloated it made everything, with signs that native is ascendant again in recent years: https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a Bienlein may be right that there are niches where memory footprint doesn't matter and there were years where it wasn't a big deal, but it's back now. RAM is really cheap today, but latency and power efficiency are the big issues. You could put 8 GBs of RAM in every smartphone right now, and there are some models which do (http://www.gsmarena.com/oneplus_5-8647.php), but the only reason most don't is because it'd suck a lot more power.
C# lost the Longhorn/Vista battle, but won the Windows 10 UWP one. Try to find the C++ talks. https://channel9.msdn.com/Events/Build/2017
Jun 23
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:
 C# lost out internally at Microsoft precisely because of how 
 bloated it made everything, with signs that native is 
 ascendant again in recent years:

 https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a
C# lost the Longhorn/Vista battle, but won the Windows 10 UWP one.
I wouldn't say C# won, UWP is implemented in C++ and supports C++. Of course, UWP is so unpopular that they eventually allowed Win32 apps into their store: https://arstechnica.com/information-technology/2016/09/desktop-apps-make-their-way-into-the-windows-store/ Now they are so desparate for people to use it that they just released a version of Windows that will only install UWP apps, Windows 10 S: https://arstechnica.com/information-technology/2017/05/microsoft-takes-on-chrome-os-with-new-windows-10-s/
 Try to find the C++ talks.

 https://channel9.msdn.com/Events/Build/2017
You seem to have missed the bit where I said C# lost _internally_. Their plan, as detailed in the Vista link, was to move all their own apps to C#, which has yet to happen. I hear C# has been very successful for corporate LoB apps, which are developed quickly and not used widely enough to spend much time on optimizing for performance. On Friday, 23 June 2017 at 22:38:29 UTC, Paulo Pinto wrote:
 Looking forward to see blazing fast D applications on the 
 Windows store.
Why? The Windows Store is a ghost town, with google not even bothering to package Chrome on there, despite their browser being the most installed and used app on Windows.
Jun 23
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:
 […]
 
 They were all about Swift, Java, Kotlin, C#.
 
Isn't Swift a native code language?
Just like Java when one uses any commercial JDK or C# when targeting UWP or Windows 8.x devices.
Jun 22
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
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
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
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