www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why do C++ programmers are not interested in D?

reply Pavel Shkadzko <p.shkadzko gmail.com> writes:
Sorry for "clickbaity" title but I believe it is discussion 
inducing.

This spring I started looking into D and trying it for some of 
the data analysis and scripting tasks. So, I am fairly new to the 
language and all its toolset (mainly using Python and Scala at 
work). I don't know C++. We do however have C++ engineers so I 
asked them around. I was quite surprised that none of them knew 
or even tried to use D. They of course heard about the language 
but that's it.

This Friday I also attended a PyTorch meetup in Munich at 
Microsoft where one of the core PyTorch developers (Adam Paszke) 
made a presentation about the future of this deep learning 
library. During presentation he mentioned that he played around 
with Hasktorch (a PyTorch inspired library in Haskell) to see how 
does PyTorch concepts go with functional style. When I approached 
him after the talk and asked if he ever thought of trying D for 
that purpose he looked surprised and confessed that he didn't 
know the language, heard about it yes but it never occurred to 
him to try and use it.

Having read about how D is a better C++ and trying it out, I have 
a feeling that it would be extremely easy for C++ devs to just 
start programming in it minutes away after getting to know its 
syntax. I saw it with my own eyes in one of the Munich meetups on 
D. But why are so few C++ devs actually do it remains a mystery 
to me. I would really like to stay away from the general 
discussion on why D is not as popular as other languages :) 
rather I'd ask around for C++ programmers who have tried D and 
share some positive experience they had so that I could spread 
the word.
Nov 19 2019
next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Tuesday, 19 November 2019 at 08:51:49 UTC, Pavel Shkadzko 
wrote:
 meetups on D. But why are so few C++ devs actually do it 
 remains a mystery to me. I would really like to stay away from 
 the general discussion on why D is not as popular as other 
 languages :) rather I'd ask around for C++ programmers who have 
 tried D and share some positive experience they had so that I 
 could spread the word.
How did you come by this conclusion? - D community is full of C++ and ex-C++ programmers! I am a former full-time C++ developer who gained interest in D almost exactly 20 years ago. I use D whenever I need "native" executables on Linux.
Nov 19 2019
parent Pavel Shkadzko <p.shkadzko gmail.com> writes:
On Tuesday, 19 November 2019 at 09:12:02 UTC, Dejan Lekic wrote:
 On Tuesday, 19 November 2019 at 08:51:49 UTC, Pavel Shkadzko 
 wrote:
 meetups on D. But why are so few C++ devs actually do it 
 remains a mystery to me. I would really like to stay away from 
 the general discussion on why D is not as popular as other 
 languages :) rather I'd ask around for C++ programmers who 
 have tried D and share some positive experience they had so 
 that I could spread the word.
How did you come by this conclusion? - D community is full of C++ and ex-C++ programmers! I am a former full-time C++ developer who gained interest in D almost exactly 20 years ago. I use D whenever I need "native" executables on Linux.
The conclusion is based solely on my own observations as a language newbie. But what triggered me is that one of the PyTorch core C++ developers didn't even consider D although the language clearly fits nicely in the machine learning domain and has been proven to be used exactly for that (see Vectorflow, https://github.com/Netflix/vectorflow). Let me just stress my concern that having a deep learning library for D these days would give it a huge boost in popularity as it once did for Lua, alas.
Nov 19 2019
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 19 November 2019 at 08:51:49 UTC, Pavel Shkadzko 
wrote:

 Having read about how D is a better C++
 But why are so few C++ devs actually do it remains a mystery to 
 me.
Unfortunately, D is not a better C++. Most notably, it has a GC, and much of the functionality of the standard library has historically required using the GC. Second, it doesn't work with legacy C++ code. That's changing, but it's a big issue. Having said that, D has massive appeal to someone like me, who needed to speed up my R programs but would rather change careers than write and maintain C++. If I had a large existing C++ codebase, I would not have moved to D either.
Nov 19 2019
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2019-11-19 at 09:28 +0000, bachmeier via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Unfortunately, D is not a better C++. Most notably, it has a GC,=20
 and much of the functionality of the standard library has=20
 historically required using the GC. Second, it doesn't work with=20
 legacy C++ code. That's changing, but it's a big issue.
[=E2=80=A6] That many C++ developers have an obsessive fear of the words garbage collec= tor is clearly an issue, independent of whether GC is actually an issue for the= ir codebases. Java (and thus Kotlin, Groovy, Clojure, Scala, etc.) and Go, and indeed to = a lesser extent D, have shown that GC is a very positive way forward in programming. C++ folk are showing an inability to think of languages other than C++, so = it seems fair enough to stop worrying about trying to replicate C++ in D. The languages have diverged and that is fine. That Rust has gained so little traction amongst C++ programmers is further evidence that the era of D as Better C++ is long past. D is D and should st= op showing angst. D's future is not to replace C++, it is to be D; a language like Go that dr= aws positively on the past, harnesses GC, and moves forward in that spirit. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Nov 19 2019
parent reply bachmeier <no spam.net> writes:
On Tuesday, 19 November 2019 at 10:57:20 UTC, Russel Winder wrote:
 On Tue, 2019-11-19 at 09:28 +0000, bachmeier via Digitalmars-d 
 wrote:
 
[…]
 Unfortunately, D is not a better C++. Most notably, it has a 
 GC, and much of the functionality of the standard library has 
 historically required using the GC. Second, it doesn't work 
 with legacy C++ code. That's changing, but it's a big issue.
[…] That many C++ developers have an obsessive fear of the words garbage collector is clearly an issue, independent of whether GC is actually an issue for their codebases.
There's a bit of a sample selection issue. Anyone open to GC moved to Java long ago. These days anyone still using C++ either has a good reason to fear the GC (certain real-time applications) or an irrational fear of the GC. The D of today would have had great success at recruiting C++ programmers 20 years ago, but by about 2005 or so, Java had already sucked up all the potential converts.
Nov 19 2019
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 19 November 2019 at 17:23:46 UTC, bachmeier wrote:
 There's a bit of a sample selection issue. Anyone open to GC 
 moved to Java long ago. These days anyone still using C++ 
 either has a good reason to fear the GC (certain real-time 
 applications) or an irrational fear of the GC.
It is not a question of fearing GC, but global collection is a rather blunt tool (compared to a scan-limited single-threaded collector, data-structure-local-collector or good ol' refcounting). Also, GC use twice as much memory or more, than carefully planned memory management.
 The D of today would have had great success at recruiting C++ 
 programmers 20 years ago, but by about 2005 or so, Java had 
 already sucked up all the potential converts.
I doubt Java had much effect on C++ programmers that gave D a shot, some C++ to D converts was absorbed back to C++ from D by C++11/C++14, and Go and Rust absorbed some others... Anyway, these days the picture is much more complex. Like how Kotlin is also aiming for the native compilation game with a LLVM backend... so with Kotlin being the default language on Android and Swift trying to become a thing on servers... well, that could skew things quite a bit for C++ programmers looking for managed languages.
Nov 19 2019
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 19 November 2019 at 17:58:14 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 19 November 2019 at 17:23:46 UTC, bachmeier wrote:
 There's a bit of a sample selection issue. Anyone open to GC 
 moved to Java long ago. These days anyone still using C++ 
 either has a good reason to fear the GC (certain real-time 
 applications) or an irrational fear of the GC.
It is not a question of fearing GC, but global collection is a rather blunt tool (compared to a scan-limited single-threaded collector, data-structure-local-collector or good ol' refcounting). Also, GC use twice as much memory or more, than carefully planned memory management.
 The D of today would have had great success at recruiting C++ 
 programmers 20 years ago, but by about 2005 or so, Java had 
 already sucked up all the potential converts.
I doubt Java had much effect on C++ programmers that gave D a shot, some C++ to D converts was absorbed back to C++ from D by C++11/C++14, and Go and Rust absorbed some others... Anyway, these days the picture is much more complex. Like how Kotlin is also aiming for the native compilation game with a LLVM backend... so with Kotlin being the default language on Android and Swift trying to become a thing on servers... well, that could skew things quite a bit for C++ programmers looking for managed languages.
And .NET absorbed a couple more with its adoption by the games industry in tooling and some major engines. Plus the Midori and Singularity learning that ended up in mainstream .NET, to the point that one can use .NET Native, .NET Core 3 and the upcoming .NET 5 for low level stuff that a couple of years ago C++ would be the only option in Windows. engines scripting capabilities is starting to be a must have on the feature list, even if it is constrained in some form. Regarding UIs, in what concerns OS SDKs, C++ has already lost the crown it had on 90's systems, nowadays it is used for the composition engine/visual layer and respective drivers, with everything else done in some managed language, with the exception of Microsoft, due to UWP being basically COM 2.0 and they need to move those MFC/ATL devs to a stack they would accept. Even Qt now has QML, with traditional C++ widgets being an option only on desktops. Qt 6 is supposed to open QML deployment scenarios back to pure C++ coding, lets see how it turns out. Right now, D doesn't look like a viable solution to any of those scenarios as C++ replacement, hence the lack of interest.
Nov 19 2019
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 20 November 2019 at 07:43:12 UTC, Paulo Pinto wrote:
 Plus the Midori and Singularity learning that ended up in 
 mainstream .NET, to the point that one can use .NET Native, 
 .NET Core 3 and the upcoming .NET 5 for low level stuff that a 
 couple of years ago C++ would be the only option in Windows.
Is .NET Native available on other platforms than Windows? Mono seems to perform less well...
 Regarding UIs, in what concerns OS SDKs, C++ has already lost 
 the crown it had on 90's systems, nowadays it is used for the 
 composition engine/visual layer and respective drivers, with 
 everything else done in some managed language, with the
Not only managed, but UI-tweaking is better done in a language that doesn't require compilation, with hot reload (changes are visible in the running application without closing it first).
 Right now, D doesn't look like a viable solution to any of 
 those scenarios as C++ replacement, hence the lack of interest.
IMO, right now there are too many similar-looking languages. Whoever stands out for some very specific use scenarios gain ground. I found it a bit interesting that the Swift Server WG has 2 people from IBM on board, maybe they see it as an alternative to Java with lower memory footprint (no GC). I wish I knew why they think Swift would be a good solution on the server.
Nov 20 2019
parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 20 November 2019 at 09:44:54 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 20 November 2019 at 07:43:12 UTC, Paulo Pinto 
 wrote:
 Plus the Midori and Singularity learning that ended up in 
 mainstream .NET, to the point that one can use .NET Native, 
 .NET Core 3 and the upcoming .NET 5 for low level stuff that a 
 couple of years ago C++ would be the only option in Windows.
Is .NET Native available on other platforms than Windows? Mono seems to perform less well...
No, but there are tons of devs that only care about a specific platform. In what concerns AOT story in .NET, besides IL2CPP and Burst from Unity, there is also Xamarin AOT toolchain used for iOS/Android, and .NET 5 roadmap plans to replace .NET Native with Mono AOT implementation, so I imagine Microsoft is planning some improvements there.
 Regarding UIs, in what concerns OS SDKs, C++ has already lost 
 the crown it had on 90's systems, nowadays it is used for the 
 composition engine/visual layer and respective drivers, with 
 everything else done in some managed language, with the
Not only managed, but UI-tweaking is better done in a language that doesn't require compilation, with hot reload (changes are visible in the running application without closing it first).
 Right now, D doesn't look like a viable solution to any of 
 those scenarios as C++ replacement, hence the lack of interest.
IMO, right now there are too many similar-looking languages. Whoever stands out for some very specific use scenarios gain ground. I found it a bit interesting that the Swift Server WG has 2 people from IBM on board, maybe they see it as an alternative to Java with lower memory footprint (no GC). I wish I knew why they think Swift would be a good solution on the server.
IBM is responsible for one Swift server framework. https://github.com/IBM-Swift/Kitura Java will get value types (with experimental version already available), and IBM has their own JVM implementations as well, so I doubt that, just being present in all fronts I guess.
Nov 20 2019
prev sibling next sibling parent reply Laeeth Isharc <Laeeth laeeth.com> writes:
On Tuesday, 19 November 2019 at 17:23:46 UTC, bachmeier wrote:
 On Tuesday, 19 November 2019 at 10:57:20 UTC, Russel Winder 
 wrote:
 On Tue, 2019-11-19 at 09:28 +0000, bachmeier via Digitalmars-d 
 wrote:
 
[…]
 Unfortunately, D is not a better C++. Most notably, it has a 
 GC, and much of the functionality of the standard library has 
 historically required using the GC. Second, it doesn't work 
 with legacy C++ code. That's changing, but it's a big issue.
[…] That many C++ developers have an obsessive fear of the words garbage collector is clearly an issue, independent of whether GC is actually an issue for their codebases.
There's a bit of a sample selection issue. Anyone open to GC moved to Java long ago. These days anyone still using C++ either has a good reason to fear the GC (certain real-time applications) or an irrational fear of the GC. The D of today would have had great success at recruiting C++ programmers 20 years ago, but by about 2005 or so, Java had already sucked up all the potential converts.
Look at the pace at which the pool of programmers is growing. I'm not sure that some of the programmers I work with were even programming at all in 2005. Myself, I wouldn't have picked up programming again if it had to be Java or C++ because life is too short. I think it's a real mistake to conceive of life as being a zero-sum game. In general, but particularly when the pool is growing. Economic decisions are taken at the margin and the potential substitutes are not what one might think. It might even be do a project in D or don't do it at all. The contender can keep growing for a long time picking up new adoption from all kinds of different places. Also in my experience if people keep insisting something is doomed and it just keeps growing it might be a bad idea to be too confident about that. From the very earliest days on Usenet people were naysaying the prospects of D. Oh well. The bigger challenges will come with continued adoption because that will change the nature of the people in the community which may require some adjustments.
Nov 19 2019
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-11-20 at 01:34 +0000, Laeeth Isharc via Digitalmars-d wrote:
 [=E2=80=A6]
=20
 Look at the pace at which the pool of programmers is growing. =20
 I'm not sure that some of the programmers I work with were even=20
 programming at all in 2005.  Myself, I wouldn't have picked up=20
 programming again if it had to be Java or C++ because life is too=20
 short.
=20
[=E2=80=A6] Also all of the hypothesis around about decline in use of C++, are missing = a crucial factor. In 1995/1996 universities stoppped teaching students langua= ges such as C++ and taught only Java. So come the millennia, all new programmer= s entering the job market knew Java and little else. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Nov 22 2019
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 22 November 2019 at 08:26:54 UTC, Russel Winder wrote:
 On Wed, 2019-11-20 at 01:34 +0000, Laeeth Isharc via 
 Digitalmars-d wrote:
 […]
 
 Look at the pace at which the pool of programmers is growing. 
 I'm not sure that some of the programmers I work with were 
 even programming at all in 2005.  Myself, I wouldn't have 
 picked up programming again if it had to be Java or C++ 
 because life is too short.
 
[…] Also all of the hypothesis around about decline in use of C++, are missing a crucial factor. In 1995/1996 universities stoppped teaching students languages such as C++ and taught only Java. So come the millennia, all new programmers entering the job market knew Java and little else.
Some universities. Mine was quite strong in C++, and still teaches it to this day. The only lectures that switched to Java in 1996/97 were compiler design and distributed systems, with artificial intelligent allowing it as alternative in addition to the Prolog/C++/Lisp trio for assignment work. It is always a question of university quality level. -- Paulo
Nov 22 2019
parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2019-11-22 at 13:39 +0000, Paulo Pinto via Digitalmars-d wrote:
 On Friday, 22 November 2019 at 08:26:54 UTC, Russel Winder wrote:
=20
[=E2=80=A6]
 Some universities.
Good point, I was wrong to imply the claim all universities.
 Mine was quite strong in C++, and still teaches it to this day.
I had been teaching C++ in term 2 (term 1 was using Miranda) at UCL and we switched to Java in both terms with a suitable change of content to do much more on algorithms and data structures. Then I moved to KCL and we switched Modula-2 to Java in terms 1 and 2 with roughyl the same course content as a= t UCL (I wonder why? :-) ).
 The only lectures that switched to Java in 1996/97 were compiler=20
 design and distributed systems, with artificial intelligent=20
 allowing it as alternative in addition to the Prolog/C++/Lisp=20
 trio for assignment work.
=20
 It is always a question of university quality level.
And indeed country. It was the top flight universities in the UK that made = the switch to Java.=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Nov 23 2019
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2019-11-19 at 17:23 +0000, bachmeier via Digitalmars-d wrote:
=20
[=E2=80=A6]
 There's a bit of a sample selection issue. Anyone open to GC=20
 moved to Java long ago. These days anyone still using C++ either=20
 has a good reason to fear the GC (certain real-time applications)=20
 or an irrational fear of the GC. The D of today would have had=20
 great success at recruiting C++ programmers 20 years ago, but by=20
 about 2005 or so, Java had already sucked up all the potential=20
 converts.
I am not sure I agree totally, but it is a very good hypothesis. The upshot really though is D should give up trying to win over C++ programmers as a strategy. Being able to wrap C+ libraries such as Qt is st= ill a good goal though. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Nov 22 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 22 November 2019 at 08:22:19 UTC, Russel Winder wrote:
 The upshot really though is D should give up trying to win over 
 C++ programmers as a strategy.
The advantage in appealing to C and C++ programmers is that people who have an interest in compilers and performant libraries tend to also know either C or C++. I essentially don't think it matters so much how many users D has, as long as it can draw in people that pull in the same direction. It doesn't really help to have a gazillion low quality do-nothing packages like npm... Stuff like Mir does help, but that is on the C-end of programming, not on the Java-end. I think there is way too much emphasis on the number of libraries or users a language has.
Nov 22 2019
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2019-11-19 at 08:51 +0000, Pavel Shkadzko via Digitalmars-d wrote:
 [=E2=80=A6]
 work). I don't know C++. We do however have C++ engineers so I=20
 asked them around. I was quite surprised that none of them knew=20
 or even tried to use D. They of course heard about the language=20
 but that's it.
Most C++ programmers work on C++ codebases and so are tied to improvements = in C++ for any and all improvements in life. That C++ has entered a 3 year standards cycle has solved many of the proble= ms C++ had in terms of evolution, and so the idea of rewriting a C++ codebase = to another language has gone out of the window =E2=80=93 it was probably unlik= ely in most cases anyway for other reasons. It is also worthy of note that the C++ community is far, far bigger than th= e D community. The social aspects of things have a big influence. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Nov 19 2019
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 19 November 2019 at 08:51:49 UTC, Pavel Shkadzko 
wrote:
 Sorry for "clickbaity" title but I believe it is discussion 
 inducing.

 This spring I started looking into D and trying it for some of 
 the data analysis and scripting tasks. So, I am fairly new to 
 the language and all its toolset (mainly using Python and Scala 
 at work). I don't know C++. We do however have C++ engineers so 
 I asked them around. I was quite surprised that none of them 
 knew or even tried to use D. They of course heard about the 
 language but that's it.
The reasons are: * C++ is the to go to language for systems programming * Any project will choose C++ over D because * C++ proven, less bugs * There are plenty of C++ engineers out there * Many tools, platforms and libraries are done in C/C++ making C++ the obvious choice. D isn't more popular because there haven't been much need for switching and that projects mostly bet on safe choices. For bare metal C++ is still the obvious choice but for applications I think C++ cannot compete anymore.
Nov 19 2019
parent reply Newbie2019 <newbie2019 gmail.com> writes:
On Tuesday, 19 November 2019 at 11:09:25 UTC, IGotD- wrote:
 The reasons are:
 * C++ is the to go to language for systems programming
 * Any project will choose C++ over D because
     * C++ proven, less bugs
     * There are plenty of C++ engineers out there
 * Many tools, platforms and libraries are done in C/C++ making 
 C++ the obvious choice.

 D isn't more popular because there haven't been much need for 
 switching and that projects mostly bet on safe choices.

 For bare metal C++ is still the obvious choice but for 
 applications I think C++ cannot compete anymore.
The question can be why C++ programmers like RUST but not D. RUST achievement: a) browser engine (firefox, webrender) b) Virtualization (firecracker, rust-virtual-machine, cloud-hypervisor, railcar , vagga ) c) database, storage engine (tikv , PumpkinDB, sled, indradb, noria, ParityDB) d) Emulators / Games / Graphics / Text editors (a lot projects on github with active users) e) System tools (there is really a lot on github) f) Web developer, WASM projects g) betters IDEs support h) BlockChain (Facebook Libra, and a lot other products worth millions or billions) i) Android and IOS. (D has Android, but not IOS) D has similar projects for web/wasm/GUI, but with less projects activity and users. I suggest D should add a grave yard page with dead projects on this site.
Nov 19 2019
next sibling parent JN <666total wp.pl> writes:
On Tuesday, 19 November 2019 at 13:01:30 UTC, Newbie2019 wrote:
 I suggest D should add a grave yard page with dead projects on 
 this site.
This already exists, kind of: http://dsource.org/projects/ Jokes aside, I think most C++ programmers who could have made the switch away from it, did that long time ago, whether to Go, Java, As for why they don't switch to D, it's mostly because it's not popular. The reason they might be switching to Rust isn't because they desire borrow checker or anything like that, most people don't care about that. But it's a language that got many things right and comes with great defaults. One package manager, one way to install, one compiler. On top of that it has solid base libraries, upon which people write higher level constructs. Also, it has a lot of popularity right now, so people can switch having confidence that the bug reports will be fixed quickly and they can find help whenever needed. Sure, D has a lot of these features too. But for a C++ programmer, many of those features they see first time and it's amazing. Package managers never took hold in C++ world, whether it's vkpkg, conan, it's all niche. But in D, Rust, etc. people can't live without it.
Nov 19 2019
prev sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 19 November 2019 at 13:01:30 UTC, Newbie2019 wrote:
 The question can be why C++ programmers like RUST but not D.

 RUST achievement:

 a) browser engine (firefox,  webrender)
 b) Virtualization (firecracker, rust-virtual-machine, 
 cloud-hypervisor, railcar , vagga  )
 c) database, storage engine (tikv , PumpkinDB, sled, indradb, 
 noria, ParityDB)
 d) Emulators / Games / Graphics / Text editors (a lot projects 
 on github with active users)
 e) System tools (there is really a lot on github)
 f) Web developer, WASM projects
 g) betters IDEs support
 h) BlockChain (Facebook Libra, and a lot other products worth 
 millions or billions)
 i) Android and IOS. (D has Android, but not IOS)

 D has similar projects for web/wasm/GUI, but with less projects 
 activity and users.

 I suggest D should add a grave yard page with dead projects on 
 this site.
I don't see Rust picking up that fast and that C++ programmers like Rust is your claim. Rust might have better support than D but that doesn't say much as both are very small compared to C++ and fringe languages. I'm used to C++ and think C++ is ugly but Rust is even worse. Take C++ meta programming and make it worse and you have Rust. Rust has gone the C++ complicated route and made even more complicated, I can't see that as a recipe for winning. In the real world the statistics are clear, simplicity rules. Major languages like Python and Java are popular because they are experienced as simpler languages. In the real world you want to get from A to B with as little effort as possible. Rust will never pick up because of this. However, D has an edge here as it can be a simpler alternative to C++ and that is why I started to use D. It currently interesting to see all those DIPs trying make Rust out of D but if it makes the language more complicated D will lose its competitiveness.
Nov 19 2019
parent Newbie2019 <newbie2019 gmail.com> writes:
On Tuesday, 19 November 2019 at 15:08:55 UTC, IGotD- wrote:
 In the real world the statistics are clear, simplicity rules. 
 Major languages like Python and Java are popular because they 
 are experienced as simpler languages. In the real world you 
 want to get from A to B with as little effort as possible. Rust 
 will never pick up because of this. However, D has an edge here 
 as it can be a simpler alternative to C++ and that is why I 
 started to use D. It currently interesting to see all those 
 DIPs trying make Rust out of D but if it makes the language 
 more complicated D will lose its competitiveness.
The Microsoft, Facebook, intel, Mozilla use Rust for billions dollar projects, I will consider that a real world Rust success case.
Nov 19 2019
prev sibling next sibling parent reply Mark <smarksc gmail.com> writes:
On Tuesday, 19 November 2019 at 08:51:49 UTC, Pavel Shkadzko 
wrote:
 Sorry for "clickbaity" title but I believe it is discussion 
 inducing.

 This spring I started looking into D and trying it for some of 
 the data analysis and scripting tasks. So, I am fairly new to 
 the language and all its toolset (mainly using Python and Scala 
 at work). I don't know C++. We do however have C++ engineers so 
 I asked them around. I was quite surprised that none of them 
 knew or even tried to use D. They of course heard about the 
 language but that's it.

 This Friday I also attended a PyTorch meetup in Munich at 
 Microsoft where one of the core PyTorch developers (Adam 
 Paszke) made a presentation about the future of this deep 
 learning library. During presentation he mentioned that he 
 played around with Hasktorch (a PyTorch inspired library in 
 Haskell) to see how does PyTorch concepts go with functional 
 style. When I approached him after the talk and asked if he 
 ever thought of trying D for that purpose he looked surprised 
 and confessed that he didn't know the language, heard about it 
 yes but it never occurred to him to try and use it.

 Having read about how D is a better C++ and trying it out, I 
 have a feeling that it would be extremely easy for C++ devs to 
 just start programming in it minutes away after getting to know 
 its syntax. I saw it with my own eyes in one of the Munich 
 meetups on D. But why are so few C++ devs actually do it 
 remains a mystery to me. I would really like to stay away from 
 the general discussion on why D is not as popular as other 
 languages :) rather I'd ask around for C++ programmers who have 
 tried D and share some positive experience they had so that I 
 could spread the word.
In addition to what others have written, here's another thing to consider: D's "killer feature" is its metaprogramming capabilities, but I don't think most C++ programmers, rightly or wrongly, care that much about metaprogramming. I think the reason Rust hasn't replaced C++ (so far, anyway) is similar - it's killer feature is "memory safety by default" but most C++ programmers that I know don't consider (lack of) memory safety to be a major problem in the language.
Nov 19 2019
next sibling parent reply Pavel Shkadzko <p.shkadzko gmail.com> writes:
On Tuesday, 19 November 2019 at 13:06:29 UTC, Mark wrote:
 In addition to what others have written, here's another thing 
 to consider: D's "killer feature" is its metaprogramming 
 capabilities, but I don't think most C++ programmers, rightly 
 or wrongly, care that much about metaprogramming. I think the 
 reason Rust hasn't replaced C++ (so far, anyway) is similar - 
 it's killer feature is "memory safety by default" but most C++ 
 programmers that I know don't consider (lack of) memory safety 
 to be a major problem in the language.
Sorry, could you please elaborate what do you mean by D "metaprogramming"?
Nov 19 2019
parent Mark <smarksc gmail.com> writes:
On Tuesday, 19 November 2019 at 13:57:07 UTC, Pavel Shkadzko 
wrote:
 On Tuesday, 19 November 2019 at 13:06:29 UTC, Mark wrote:
 In addition to what others have written, here's another thing 
 to consider: D's "killer feature" is its metaprogramming 
 capabilities, but I don't think most C++ programmers, rightly 
 or wrongly, care that much about metaprogramming. I think the 
 reason Rust hasn't replaced C++ (so far, anyway) is similar - 
 it's killer feature is "memory safety by default" but most C++ 
 programmers that I know don't consider (lack of) memory safety 
 to be a major problem in the language.
Sorry, could you please elaborate what do you mean by D "metaprogramming"?
Better known in the community as "Design by Introspection". See for instance: https://tour.dlang.org/tour/en/gems/template-meta-programming
Nov 19 2019
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 19 November 2019 at 13:06:29 UTC, Mark wrote:
 In addition to what others have written, here's another thing 
 to consider: D's "killer feature" is its metaprogramming 
 capabilities, but I don't think most C++ programmers, rightly 
 or wrongly, care that much about metaprogramming.
I think library authors do, though. Anyway there are issues related to meta programming in C++, D, and Rust. But they all also improve on that for every significant version bump. Whoever stops evolving their metaprogramming features will fall behind. Rust is getting const generics eventually and C++ has added many library features and some minor language tweaks. It would be a good idea for D to make some statements about what is coming on the metaprogramming front.
 I think the reason Rust hasn't replaced C++ (so far, anyway) is 
 similar - it's killer feature is "memory safety by default" but 
 most C++ programmers that I know don't consider (lack of) 
 memory safety to be a major problem in the language.
There are certain things in rust that is verbose in Rust and that would be annoying to many C++ programmers. E.g. if you don't want to initialise a variable then you have to wrap the type in MaybeUninit<T>, and then use mem::transmute<_,T>(variable) as a cast after the variable has been initialized. This level of safe/unsafe type system verbosity is only ok if you almost always initialise variables. I think the default mode for many C++ programmers is to not trust the optimiser to get it right. Which can be a liability, it really depends on whether you want a primarily low level language with some high level capabilities (C++) or a primarily high level language with some low level capabilities (D and Rust).
Nov 19 2019
next sibling parent reply Ola Fosheim Gr <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 19 November 2019 at 14:36:06 UTC, Ola Fosheim Grøstad 
wrote:
 Whoever stops evolving their metaprogramming features will fall 
 behind.
Btw, Go is also actively pursuing generics now: https://go-review.googlesource.com/c/go/+/187317/ https://blog.golang.org/why-generics
Nov 19 2019
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/19/19 9:55 AM, Ola Fosheim Gr wrote:
 On Tuesday, 19 November 2019 at 14:36:06 UTC, Ola Fosheim Grøstad wrote:
 Whoever stops evolving their metaprogramming features will fall behind.
Btw, Go is also actively pursuing generics now: https://go-review.googlesource.com/c/go/+/187317/ https://blog.golang.org/why-generics
Interesting they use the term "generics", it looks very much like they are putting in templates, which are vastly different from generics on many languages. It also looks like the call syntax does not use angle brackets, but just normal parentheses, a huge win for sure. -Steve
Nov 19 2019
next sibling parent Ola Fosheim Gr <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 19 November 2019 at 16:11:00 UTC, Steven 
Schveighoffer wrote:
 Interesting they use the term "generics", it looks very much 
 like they are putting in templates, which are vastly different 
 from generics on many languages.
Well, I don't know. Seems like they haven't quite decided on the semantics, but implement it in order to get feedback on actual use. The umbrella term is «generic programming», so templates is perhaps more like a special case of generics. Also, it could create C++ like expectations, perhaps. I assume they will go for something simpler.
Nov 19 2019
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 19.11.19 17:11, Steven Schveighoffer wrote:
 On 11/19/19 9:55 AM, Ola Fosheim Gr wrote:
 On Tuesday, 19 November 2019 at 14:36:06 UTC, Ola Fosheim Grøstad wrote:
 Whoever stops evolving their metaprogramming features will fall behind.
Btw, Go is also actively pursuing generics now: https://go-review.googlesource.com/c/go/+/187317/ https://blog.golang.org/why-generics
Interesting they use the term "generics", it looks very much like they are putting in templates, which are vastly different from generics on many languages. ...
They do the type checking modularly, but it indeed appears they are not aiming to support generic methods on interfaces, directly contradicting: "In Go, we’ve aimed to reduce complexity through independent, orthogonal language features that can be combined freely. We reduce complexity by making the individual features simple, and we maximize the benefit of the features by permitting their free combination. We want to do the same with generics." Also: - "The contract simply says that T has to implement the String method. You may notice that this contract looks like the fmt.Stringer interface, so it's worth pointing out that the argument of the ToStrings function is not a slice of fmt.Stringer." - "After all, in Go, only built-in types support operators."
 It also looks like the call syntax does not use angle brackets, but just 
 normal parentheses, a huge win for sure.
 
 -Steve
It's another orthogonality violation. They don't support curried function definitions for other types of arguments. (Of course, D is no more orthogonal, but it doesn't claim it as a core tenet.)
Nov 23 2019
prev sibling parent reply Mark <smarksc gmail.com> writes:
On Tuesday, 19 November 2019 at 14:36:06 UTC, Ola Fosheim Grøstad 
wrote:
 I think library authors do, though. Anyway there are issues 
 related to meta programming in C++, D, and Rust. But they all 
 also improve on that for every significant version bump. 
 Whoever stops evolving their metaprogramming features will fall 
 behind.

 Rust is getting const generics eventually and C++ has added 
 many library features and some minor language tweaks. It would 
 be a good idea for D to make some statements about what is 
 coming on the metaprogramming front.
Yes, I think some support for generic programming is generally expected from any modern programming language. This greatly benefits library authors and, in turn, library users. I'm not surprised that Go is also pursuing generics now. But in my view it's not clear how far languages should take their MP (metaprogramming) support. D has more MP support than any other statically-typed language that I know of, but even D hasn't taken it to the extreme: - It doesn't have AST macros and, as far as I know, there are no plans to ever include them in the language. - Compile-time function evaluation is subject to various restrictions: for instance, you can't make arbitrary system calls. I'm not up to speed on the current limitations of the CTFE engine, but I believe W&A want compilation to be deterministic, and this naturally restricts the operations allowed at compile-time. (Someone please correct me if I'm wrong) This brings to mind the adage "absolute power corrupts absolutely". saying "I love generics, extension methods and lambda expressions, but that's good enough for me. I can live without `static if` and a full CTFE engine". That said, it's not like crowd. Maybe most programmers (or at least library authors) in these languages *do* wish for D-level MP support in their language. But that's a question that needs to be investigated; the answer is not obvious at all IMO.
Nov 23 2019
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 23 November 2019 at 19:35:55 UTC, Mark wrote:
 But in my view it's not clear how far languages should take 
 their MP (metaprogramming) support. D has more MP support than 
 any other statically-typed language that I know of, but even D 
 hasn't taken it to the extreme:
 - It doesn't have AST macros and, as far as I know, there are 
 no plans to ever include them in the language.
Doesn't Nim have AST macros, though? I haven't gotten around to trying Nim yet. Too many new compile-time languages...
 calls. I'm not up to speed on the current limitations of the 
 CTFE engine, but I believe W&A want compilation to be 
 deterministic, and this naturally restricts the operations 
 allowed at compile-time.
Yes, C++ have some more limitations than D, but is fairly close. More restrictions seem to be lifted with each version (constexpr). Except of course, D allows building code from strings. I personally think that is one step to far, and would rather have used some kind of limited AST building capability, but many people seem to use string mixins. The question remains though: are they being used as a last resort or are they used in situations where more structured approaches would have been better? One problem with string mixins is that source-to-source translation becomes very difficult. So then you cannot really improve the syntax, e.g. by machine translating all D2 source code to D3 source code(if it ever happens). So there certainly are downsides to allowing this level of metaprogramming (string mixins/AST) in terms of being "forward compatible" (which requires the translation program to fully "understand" the old sourcecode). The Go authors put a lot of emphasis on automatic source-to-source translation between versions. It will be interesting to see if they can keep delivering on that with Go2 after they get Generics in. It clearly is a big advantage though, in terms of evolving a language over time.

 saying "I love generics, extension methods and lambda 
 expressions, but that's good enough for me. I can live without 
 `static if` and a full CTFE engine". That said, it's not like 

 crowd.
C++ library authors have been using various involved template/multiple-inheritance techniques for the same effect. So they clearly see the value of being able to do it. And they also got "if constexpr" which is a limited version of "static if".
 Maybe most programmers (or at least library authors) in these 
 languages *do* wish for D-level MP support in their language. 
 But that's a question that needs to be investigated; the answer 
 is not obvious at all IMO.
Yeah, well, I want good MP support, but I also want Go-style source-to-source translation so that language syntax (and semantics) improve over time and isn't locked down forever. A hard nut to crack perhaps.
Nov 23 2019
prev sibling parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Saturday, 23 November 2019 at 19:35:55 UTC, Mark wrote:

 saying "I love generics, extension methods and lambda 
 expressions, but that's good enough for me. I can live without 
 `static if` and a full CTFE engine". That said, it's not like 

 crowd. Maybe most programmers (or at least library authors) in 
 these languages *do* wish for D-level MP support in their 
 language. But that's a question that needs to be investigated; 
 the answer is not obvious at all IMO.
generation capabilities. It may not be well known, but there are frameworks out there that look at classes in other libraries at runtime and dynamically generate new bytecode to wrap those for various purposes. Some versions of JBoss did this to inject authorization checks in EJBs: they'd create a new anonymous implementation of the EJB's interface that wraps every function with such a test that forwards to the actual EJB implementation. In most cases, however, you get away without explicit code generation. You can quite easily call unknown methods through reflection or query and change the values of variables. All of this can also ignore all access specifiers as it bypasses the compiler. These features are really, really powerful cannons. Also, nothing prevents you from aiming them at your own feet. It's a good thing that they are generally used very sparingly (except when they aren't).
Nov 27 2019
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/19/19 3:51 AM, Pavel Shkadzko wrote:
 Sorry for "clickbaity" title but I believe it is discussion inducing.
 
 This spring I started looking into D and trying it for some of the data 
 analysis and scripting tasks. So, I am fairly new to the language and 
 all its toolset (mainly using Python and Scala at work). I don't know 
 C++. We do however have C++ engineers so I asked them around. I was 
 quite surprised that none of them knew or even tried to use D. They of 
 course heard about the language but that's it.
 
 This Friday I also attended a PyTorch meetup in Munich at Microsoft 
 where one of the core PyTorch developers (Adam Paszke) made a 
 presentation about the future of this deep learning library. During 
 presentation he mentioned that he played around with Hasktorch (a 
 PyTorch inspired library in Haskell) to see how does PyTorch concepts go 
 with functional style. When I approached him after the talk and asked if 
 he ever thought of trying D for that purpose he looked surprised and 
 confessed that he didn't know the language, heard about it yes but it 
 never occurred to him to try and use it.
I think it pretty much has to do with 1. what can I get my employer to accept as a language to use and 2. How easy is it to interface with my existing code base. I think the complaints about the GC are way overblown, they are the "Never" crowd. E.g. the ones who will never choose D for whatever reason. If you fix that reason, they'll find another one. Yes, I know there are certain places where the GC is no good for that domain (e.g. AAA games), but there are much more important problems to solve for those domains (i.e. atomics and lock-free message passing), and we do give tools to prevent GC usage ( nogc and betterC). But on my first point above, not many will accept D as a language to base their company on. The ones who do seem to have shined through with success stories (Sociomantic, Weka, Symmetry), but it's just less risky to use C++ in many minds. On the second point, we need to get to a place where via tools (dpp) or compiler adjustments (extern C++) we can interface NATIVELY with existing C++ code. One of the most important revelations from Atila, who is obviously a VERY pro-D person, is when he still picked C++ for a project at the company he worked for despite having sole discretion over whether to use D or not. He did it because all the code was already C and to do it in C++ means "I just can include the headers I need". For D, he would have to port much of those headers to D by hand. We are getting there. And honestly, I'm fine with D being it's own thing and not attracting huge swaths of C++ programmers. They'll figure it out eventually, and there is something to not chirping about how much better D is than C++ when sometimes the initial experience can be so negative on your expectations (stories I hear all the time from pro-D people who convinced coworkers to try out D). I think we are best off not lamenting about the lack of C++ immigrants. -Steve
Nov 19 2019
parent reply Laeeth Isharc <Laeeth laeeth.com> writes:
On Tuesday, 19 November 2019 at 16:24:38 UTC, Steven 
Schveighoffer wrote:
 On 11/19/19 3:51 AM, Pavel Shkadzko wrote:
 Sorry for "clickbaity" title but I believe it is discussion 
 inducing.
 
 This spring I started looking into D and trying it for some of 
 the data analysis and scripting tasks. So, I am fairly new to 
 the language and all its toolset (mainly using Python and 
 Scala at work). I don't know C++. We do however have C++ 
 engineers so I asked them around. I was quite surprised that 
 none of them knew or even tried to use D. They of course heard 
 about the language but that's it.
 
 This Friday I also attended a PyTorch meetup in Munich at 
 Microsoft where one of the core PyTorch developers (Adam 
 Paszke) made a presentation about the future of this deep 
 learning library. During presentation he mentioned that he 
 played around with Hasktorch (a PyTorch inspired library in 
 Haskell) to see how does PyTorch concepts go with functional 
 style. When I approached him after the talk and asked if he 
 ever thought of trying D for that purpose he looked surprised 
 and confessed that he didn't know the language, heard about it 
 yes but it never occurred to him to try and use it.
I think it pretty much has to do with 1. what can I get my employer to accept as a language to use and 2. How easy is it to interface with my existing code base. I think the complaints about the GC are way overblown, they are the "Never" crowd. E.g. the ones who will never choose D for whatever reason. If you fix that reason, they'll find another one. Yes, I know there are certain places where the GC is no good for that domain (e.g. AAA games), but there are much more important problems to solve for those domains (i.e. atomics and lock-free message passing), and we do give tools to prevent GC usage ( nogc and betterC). But on my first point above, not many will accept D as a language to base their company on. The ones who do seem to have shined through with success stories (Sociomantic, Weka, Symmetry), but it's just less risky to use C++ in many minds. On the second point, we need to get to a place where via tools (dpp) or compiler adjustments (extern C++) we can interface NATIVELY with existing C++ code. One of the most important revelations from Atila, who is obviously a VERY pro-D person, is when he still picked C++ for a project at the company he worked for despite having sole discretion over whether to use D or not. He did it because all the code was already C and to do it in C++ means "I just can include the headers I need". For D, he would have to port much of those headers to D by hand. We are getting there. And honestly, I'm fine with D being it's own thing and not attracting huge swaths of C++ programmers. They'll figure it out eventually, and there is something to not chirping about how much better D is than C++ when sometimes the initial experience can be so negative on your expectations (stories I hear all the time from pro-D people who convinced coworkers to try out D). I think we are best off not lamenting about the lack of C++ immigrants. -Steve
Peter Thiel says competition is for losers. It's a mistake to think that if one emerging language succeeds then another must fail. Interviewing guys from a finance background they are much or python mindset. The set of people that talk about programming and get the attention, that's only a particular slice of enterprise users and that world moves very slowly. It's not like you hear much discussion about how D is stealing market share from Pascal and VBA (or even merely just from that functional programming language known as Excel). But D will be replacing Pascal at Bastiaan's company and implicitly tools written in D are replacing VBA here. I asked the boyfriend of a friend who was at Uber and Nvidia how they would tackle what we had done with SIL and he said too ambitious these days for Nvidia. At Uber they would have put 20 reasonably senior engineers on it. John was talking to a reasonably senior technical guy from a bank at a social event. Smart chap who could anticipate the problems there would be. It was out of his reality that we could do what we do,that there wasn't a large team working on it or that it didn't take many years. We don't even have twenty programmers across all of Symmetry across all projects though we do have people who don't consider themselves programmers but write code. And the initial development of SIL was essentially one person working on it at any one time in the first phase. It might be bigger now but core SIL last I checked was 5k SLoC versus 20k for readline. So you can do things that are like science fiction to others if you don't mind making different choices and paying the price for it - immense social pressure, tooling challenges and the like. Most people shouldn't try to make that choice because their context isn't suitable for it. Look at the budgets being spent on digital transformation. I don't think the pool of programmers is going to stop growing just yet and I doubt people will become less interested in native code. If C++ picks up more D features that's great because it's still C++ and a few of those who get used to things in C++ will thereby become a bit more receptive to using D and some will switch. Yes c++ interop is important. Dpp just keeps getting better and will handle more in time and for a zero overhead approach that or dstep for C is the best choice. But, as is well known, C++ is an interpreted language that allows you to instantiate templates a runtime. Okay, I am just kidding, but it can be true if you want it to be using cling from CERN. It won't be that fast and for our purposes we used it in a way that is easy but will add more overhead. However for lots of things just being able to call C++ libraries without manual work opens up a lot and later if it matters you can make it faster. So we can call quite a lot of C++ from D using cling already and more will follow in time. We will open source when ready. It's not bad to be able to use c++ libraries from our little DSL. it's not difficult though. Python will follow too and work Atila is doing on autowrap PyNIH will be useful. I think it's not really helpful to worry about what others are doing - honourably steal ideas, sure. But the most important thing is to do good work and make the language, library and ecosystem better. If that keeps happening then adoption will follow. You can't force adoption to go faster than what the ecosystem is ready for. Very fast growth - you know that brings other kinds of challenges, believe me. If D would bring commercial benefits at work but people you work with can't see it, then either you will have to try putting personal time into demonstrating the benefits like Ali, Bastiaan and I did; or you will need to recognise that your workplace runs on different principles. It might well be easier to get a job writing D than to persuade your colleagues to switch. We are hiring at least twenty people and we aren't the only ones hiring people to write D. So there are choices.
Nov 19 2019
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 20 November 2019 at 01:19:32 UTC, Laeeth Isharc 
wrote:
 [snip]


 It won't be that fast and for our purposes we used it in a way 
 that is easy but will add more overhead.  However for lots of 
 things just being able to call C++ libraries without manual 
 work opens up a lot and later if it matters you can make it 
 faster.  So we can call quite a lot of C++ from D using cling 
 already and more will follow in time.  We will open source when 
 ready.
Any additional details you can provide on this, I would find interesting. For instance, are you using a D interpreter and then Cling as the C++ interpreter to get the C++ code working in the interpreter? I wouldn't think you would need Cling if you're compiling ahead of time. Also, I noticed jupyter-wire at the symmetryinvestments repository as a replacement for jupyterd. Is this meant to be infrastructure that some other tool will build on? Thanks.
Nov 19 2019
parent reply Laeeth isharc <laeeth laeeth.com> writes:
On Wednesday, 20 November 2019 at 02:56:35 UTC, jmh530 wrote:
 On Wednesday, 20 November 2019 at 01:19:32 UTC, Laeeth Isharc 
 wrote:
 [snip]


 It won't be that fast and for our purposes we used it in a way 
 that is easy but will add more overhead.  However for lots of 
 things just being able to call C++ libraries without manual 
 work opens up a lot and later if it matters you can make it 
 faster.  So we can call quite a lot of C++ from D using cling 
 already and more will follow in time.  We will open source 
 when ready.
Any additional details you can provide on this, I would find interesting. For instance, are you using a D interpreter and then Cling as the C++ interpreter to get the C++ code working in the interpreter? I wouldn't think you would need Cling if you're compiling ahead of time. Also, I noticed jupyter-wire at the symmetryinvestments repository as a replacement for jupyterd. Is this meant to be infrastructure that some other tool will build on? Thanks.
Right now we have a DSL written in D. And cling is used at runtime to load a C++ library and register the types and functions. Maybe it's binderoo inside out but without auto reloading. It's a bigger project to make it just work for D and we will do that in time and open source when ready. Probably generating D bindings and wrappers. If anyone wants to be paid to work on that part time we are hiring. You can do crazy things like generate c++ code at runtime in D and just call it. Like string mixins but for C++ and at runtime. Atila wants to have a D interpreter or JIT. I think that would be very powerful, particularly if you could allow incremental compilation like with cling. I had a crazy thought of repurposing the ctfe back end written by Stefan Koch for that though I guess it would need better memory management in DMD first. It feels to me that it's an ambitious project though not an enormous one to have D being able to just call C++ by parsing headers and vice versa (via introspecting on D side and compiling generated cpp headers as a string at runtime / startup). At that point you have C++ libraries and can incrementally replace a C++ codebase with D. Maybe not quite zero overhead but for us make it work then make it fast. Jupyter wire allows you to write Jupyter kernels in D. We use it for our DSL. You could hook up to drepl now and if we had a D interpreter you could use that instead. Sebastiaan Koppe just created a pull request to add Jupyter widgets to Jupyter wire. He has also written a simple widget in D compiling to web assembly. Somebody wrote part of a widget in Rust and it was a tech talk in itself that drew a lot of interest.
Nov 26 2019
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 26 November 2019 at 22:42:45 UTC, Laeeth isharc wrote:

 Atila wants to have a D interpreter or JIT.  I think that would 
 be very powerful, particularly if you could allow incremental 
 compilation like with cling.
Maybe Atila can answer better, why the LLVM JIT machinery is not already suitable for that? I remember that for newCTFE was discarded for startup performance problems, but if the use case is different ...
Nov 27 2019
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 26 November 2019 at 22:42:45 UTC, Laeeth isharc wrote:
 [snip]
Thanks. That was interesting.
Nov 27 2019
prev sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 20 November 2019 at 01:19:32 UTC, Laeeth Isharc 
wrote:
 I think it's not really helpful to worry about what others are 
 doing - honourably steal ideas, sure.  But the most important 
 thing is to do good work and make the language, library and 
 ecosystem better.  If that keeps happening then adoption will 
 follow.
There are a lot of threads of these "why D isn't picking up", "D is dead" and so on. Why not enjoy programming in D instead of fearing the walls are going down any second. I'm actually an example. It took 20 years for me to find D. I knew about its existence but there wasn't any real reason to switch from C++ to D. C++ did its job and it was proven technology. The reason I started to finally look into to D is that as time goes on you're expected to do more with less and that's where C++ starts to show its limits. Programs require more today, especially when it comes to communications, DB interactions. Complexity also seem to find its way down into smaller systems as well. Now it is not unusual that small embedded systems should talk to the world through the internet and access databases, both local and server. 10 years ago this was more unusual but it is quickly becoming standard. Also 20 years ago C++ was less template heavy. You pretty much used C++ as an object oriented language and only touched templates when you needed generics. Today I see much more templates in C++ which reduces the readability a lot. Many programmers also want to show off their template skills but it doesn't help the aesthetics of the program. D has more verbose templates which was for me another reason I wanted to move from C++.
Nov 20 2019
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 20 November 2019 at 12:20:45 UTC, IGotD- wrote:
 doesn't help the aesthetics of the program. D has more verbose 
 templates which was for me another reason I wanted to move from 
 C++.
I assume you meant that D has less verbose templates? Yes, that is an issue in C++, it is getting better, but still not great. Did you move to D because of memory safety? Or was that a not a major issue for you in C++?
Nov 20 2019
parent reply IGotD- <nise nise.com> writes:
On Wednesday, 20 November 2019 at 12:27:49 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 20 November 2019 at 12:20:45 UTC, IGotD- wrote:
 doesn't help the aesthetics of the program. D has more verbose 
 templates which was for me another reason I wanted to move 
 from C++.
I assume you meant that D has less verbose templates? Yes, that is an issue in C++, it is getting better, but still not great. Did you move to D because of memory safety? Or was that a not a major issue for you in C++?
Yes, I made mistake, I meant that D has shorter and readable templates. Memory safety is not a deal breaker but nice to have for example GC helps speeding up development as you get one less issue to think about but leaking programs are easy to debug. Bounds checking is the most important safety feature as these bugs can manifest themselves so differently and can be hard to find. C++ can find memory overwrites as well, for example MSVC put guards between variables on the stack an heap in debug mode. I would say ergonomics (ex. boiler plate code, library user friendliness) play just as big role as memory safety. The main reason I moved to D was that I found that the language was more productive.
Nov 20 2019
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 20 November 2019 at 14:02:22 UTC, IGotD- wrote:
 Memory safety is not a deal breaker but nice to have for 
 example GC helps speeding up development as you get one less 
 issue to think about but leaking programs are easy to debug.
Automatic memory management makes the initial design phase easier, restructuring carefully designed manual memory management code at the early stage can be costly/annoying. True.
 Bounds checking is the most important safety feature as these 
 bugs can manifest themselves so differently and can be hard to 
 find.
Right, I think there are some tools to do it for C/C++ as well, but it isn't the default. Well, it is the default if you use the array.at(index) member, but I guess people tend to forget that it exists. It probably should be the default in basic debug builds.
Nov 20 2019
parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 20 November 2019 at 20:32:27 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 20 November 2019 at 14:02:22 UTC, IGotD- wrote:
 Memory safety is not a deal breaker but nice to have for 
 example GC helps speeding up development as you get one less 
 issue to think about but leaking programs are easy to debug.
Automatic memory management makes the initial design phase easier, restructuring carefully designed manual memory management code at the early stage can be costly/annoying. True.
 Bounds checking is the most important safety feature as these 
 bugs can manifest themselves so differently and can be hard to 
 find.
Right, I think there are some tools to do it for C/C++ as well, but it isn't the default. Well, it is the default if you use the array.at(index) member, but I guess people tend to forget that it exists. It probably should be the default in basic debug builds.
It is the default in Visual C++ debug builds, on Solaris SPARC, and on Android as of the latest NDK release.
Nov 20 2019
prev sibling next sibling parent Ethan <gooberman gmail.com> writes:
On Tuesday, 19 November 2019 at 08:51:49 UTC, Pavel Shkadzko 
wrote:
 But why are so few C++ devs actually do it remains a mystery to 
 me.
I've not read the rest of this thread. But in my experience, it was entirely that C++ programmers still need to work with their C++ codebases and need a way to hook in to that. See D++ and Binderoo for different approaches to the problem there, but they're both still not mature enough for what would actually be needed for C++ programmers to start moving their codebases to D.
Nov 21 2019
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 19 November 2019 at 08:51:49 UTC, Pavel Shkadzko 
wrote:
 This spring I started looking into D and trying it for some of 
 the data analysis and scripting tasks. So, I am fairly new to 
 the language and all its toolset (mainly using Python and Scala 
 at work). I don't know C++. We do however have C++ engineers so 
 I asked them around. I was quite surprised that none of them 
 knew or even tried to use D. They of course heard about the 
 language but that's it.
I was a C++ programmer for a while in various set and settings. And I was very much interested in D since the first day of my first job with C++! One of the common feature of the places using C++ is, for lack of a better word, conservativeness. The fact is that the part of C++ programmers that were most interested in new techniques moved problems. When being a C++ programmer you are subtly trained to think C++ is all that ou need and "there are no alternatives". It is because everything takes longer, so you like the result of you work (pain?) with more passion. At this point in time the set of people who genuinely should only use C++ (because only that compiler is provided) are mostly the embedded engineers, and people stuck in legacy. Conservativeness affects the organization to the point it is also more likely to be a follower and react to the market, rather than innovate. C++ers in innovative companies takes up D very quickly. With C++ you are also stuck in forever learning mode. Maybe learning the new move constructor stuff is going to make life easier? C++ is updated way faster than practionners can handle, strangely enough D has more respect for your time. It's not very surprinsing that it takes a new language (Python) to foster macjine learning on the front stage. You can read up on "diffusion of innovation" to see the social structures involved and the particular mindset of late adopters (versus "early adopters" like forum users here). https://books.google.fr/books?id=4N4_MUkcQy4C&lpg=PA13&ots=82-BfO7WWP&dq=Scratch%20the%20surface%20and%20you%E2%80%99ll%20find%20these%20real-world%20inhabitants%20are%20filled%20with%20pessimism%20and%20despair&hl=fr&pg=PA13#v=onepage&q&f=false
Nov 22 2019
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 22 November 2019 at 14:31:46 UTC, Guillaume Piolat 
wrote:
 With C++ you are also stuck in forever learning mode. Maybe 
 learning the new move constructor stuff is going to make life 
 easier? C++ is updated way faster than practionners can handle, 
 strangely enough D has more respect for your time.
Actually, that is a myth. There have been very few language changes in C++, and they are basically non-breaking. Most of the changes have been on a library level or as syntactical sugar. - Lambdas er wrapped-up objects. So mostly syntactical. - Stackless coroutines are wrapped-up promises. - Move semantics is type casting (they added && with some peculiar rules to avoid some user errors). - Type traits are mostly library constructs. The basic problem with C++ is that it cannot take on breaking changes, so it is stuck with some seemingly arbitrary exceptions and restrictions, and unification can sometimes be difficult to understand. This is really a consequence of C++ being primarily C with some extras like OO, exceptions, overloading and most code written prior to 2011 was C code with some OO stuff and simple templating where OO fell short in terms of performance. The biggest issue many have with C++ is that C++ cannot clean up their syntax and semantics. D can though.
Nov 23 2019
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 23 November 2019 at 09:09:58 UTC, Ola Fosheim 
Grøstad wrote:
 On Friday, 22 November 2019 at 14:31:46 UTC, Guillaume Piolat 
 wrote:
 With C++ you are also stuck in forever learning mode. Maybe 
 learning the new move constructor stuff is going to make life 
 easier? C++ is updated way faster than practionners can 
 handle, strangely enough D has more respect for your time.
Actually, that is a myth. There have been very few language changes in C++, and they are basically non-breaking. Most of the changes have been on a library level or as syntactical sugar.
That doesn't match my experience _at all_. Have you worked in C++ in a professional capacity? C++ has a major version every 3 years, that comes with myriads of traps and new best practices. The new stuff is non-breaking, except by living in that ecosystem you will inevitable be exposed to approximately all parts of the language. That's a huge mental load to spend. Last time I touched C++ (2015) people were _in some companies_ starting to use C++11 (30% of it), because the compilers are necessarily lagging behind the C++ comittee. To quote my competition:
 Now we have const, constexpr, if constexpr, consteval and 
 std::is_constant_evaluated()
Who said C++ was hard to learn/teach?
Nov 24 2019
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 24 November 2019 at 13:01:13 UTC, Guillaume Piolat 
wrote:
 That doesn't match my experience _at all_. Have you worked in 
 C++ in a professional capacity?
Please drop the ad hominems. It is completely irrelevant. (yes, but still 100% irrelevant).
 C++ has a major version every 3 years, that comes with myriads 
 of traps and new best practices.
C++ is seeing growth because it is regularly updated. That's just a fact. So that is clearly not viewed as a problem with those that adopt it... (if it was there would be no growth). However most of the _language_ changes are minor, and either syntactical sugar for common practice or simplifications of things that was a drag to write (e.g. template magic being replaced by CTFE). The biggest semantic change might actually be metaprogramming things like decltype(), but such changes are not revolutionary in any way. Ref. https://en.cppreference.com/w/cpp/language/history C++20 langauge changes: « 3-way comparison operator <=> and operator==() = default, designated initializers, init-statements and initializers in range-for, char8_t, [[no_unique_address]], [[likely]], [[unlikely]], pack-expansions in lambda captures, removed the requirement to use typename to disambiguate types in many contexts, consteval, further relaxed constexpr, signed integers are 2's complement, aggregate initialization using parentheses, array new can deduce array size » Basically _nothing_!
 The new stuff is non-breaking, except by living in that 
 ecosystem you will inevitable be exposed to approximately all 
 parts of the language.
Performance oriented libraries are usually conservative in what they use in the API? Actually, many C++ codebases on github are C with a bit of C++ here and there...
 Now we have const, constexpr, if constexpr, consteval and 
 std::is_constant_evaluated()
Who said C++ was hard to learn/teach?
Well, constexpr on functions is in the same vein as D attributes like "pure". It should have been the default. Basically, if for a programmer with a good understanding of C++11 and common C++ patterns with templates then C++14/17/20 is not a big hurdle to overcome. Now, getting a good understanding of C+11 and common C++ meta-programming patterns is a big hurdle... but that has nothing to do with language changes. C++ has always been like that.
Nov 24 2019
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 24 November 2019 at 13:29:12 UTC, Ola Fosheim Grøstad 
wrote:
 C++ is seeing growth because it is regularly updated.
By what metrics C++ would be growing? Because it doesn't seem like the native space is expanding. https://www.tiobe.com/tiobe-index/cplusplus/ https://www.youtube.com/watch?v=Og847HVwRSI&t=228
Nov 24 2019
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 24 November 2019 at 13:47:42 UTC, Guillaume Piolat 
wrote:
 On Sunday, 24 November 2019 at 13:29:12 UTC, Ola Fosheim 
 Grøstad wrote:
 C++ is seeing growth because it is regularly updated.
By what metrics C++ would be growing? Because it doesn't seem
https://www.openhub.net/languages/compare?language_name%5B%5D=cpp&language_name%5B%5D=-1&measure=contributors FWIW, C++ has always been a troubled language. Cfront was slow. After Cfront C++ compilers implemented C++ slightly differently so you could not easily write portable code. After C++ was standardized compiler impementors had a hard time implementing all of it. After most of it was implemented you'd still have to optimize your code in C-like manner as optimizers weren't on the level they are today. So you might start with something clean and end up with something you didn't like... And you had to manage your own memory. And to use RAII you had write lots of verbose class descriptions. Overall C++11/17/20 with clang/gcc is a much easier language to work with than C++ ever was. Everything is relative. But C++ has never been "clean". Ever. D is clearly a much easier language to get started with in my opinion. Although, if you read the C++ reddit, some C++ programmers claim that D is too similar to C++ to be worth the switch. Maybe they are right, but D has much more room for making changes... C++'s backwards compatibility requirement is gridlocking the design space, so with every addition C++ is locked down more and more...
Nov 24 2019
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 24 November 2019 at 13:47:42 UTC, Guillaume Piolat 
wrote:
 On Sunday, 24 November 2019 at 13:29:12 UTC, Ola Fosheim 
 Grøstad wrote:
 C++ is seeing growth because it is regularly updated.
By what metrics C++ would be growing? Because it doesn't seem like the native space is expanding. https://www.tiobe.com/tiobe-index/cplusplus/ https://www.youtube.com/watch?v=Og847HVwRSI&t=228
By being the go to language in game engines, GPGPU (NVIDIA now designs their cards to be ISO C++ friendly), the language that is used in Metal shaders and IO Kit, the rewrite from React Native for Windows and OS X taken up by Microsoft, what gets called from Java/.NET when extra native help is needed,.... Now if the metric is having GUI toolkits in C++, like those from the 90's, then yeah it pretty much lost it, with Qt, WinUI and wxWidgets being the last ones standing. Or doing stuff like CMS. Hope no one is doing them in C++.
Nov 24 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 24 November 2019 at 17:53:18 UTC, Paulo Pinto wrote:
 On Sunday, 24 November 2019 at 13:47:42 UTC, Guillaume Piolat 
 Now if the metric is having GUI toolkits in C++, like those 
 from the 90's, then yeah it pretty much lost it, with Qt, WinUI 
 and wxWidgets being the last ones standing.
Basically all GUI engines are written in C/C++, but thanks to current CPUs and JIT compilers you are basically better off using a high level language that can do hot updates (updating the GUI of a running application). Also, several typical C projects transition to C++. I expect that trend to continue, even if the transition ratio isn't overwhelming: https://www.openhub.net/languages/compare?utf8=%E2%9C%93&measure=projects&language_name%5B%5D=cpp&language_name%5B%5D=c&language_name%5B%5D=-1&commit=Update
Nov 24 2019
prev sibling parent reply Jab <jab_293 gmall.com> writes:
On Sunday, 24 November 2019 at 13:01:13 UTC, Guillaume Piolat 
wrote:
 On Saturday, 23 November 2019 at 09:09:58 UTC, Ola Fosheim 
 Grøstad wrote:
 On Friday, 22 November 2019 at 14:31:46 UTC, Guillaume Piolat 
 wrote:
 With C++ you are also stuck in forever learning mode. Maybe 
 learning the new move constructor stuff is going to make life 
 easier? C++ is updated way faster than practionners can 
 handle, strangely enough D has more respect for your time.
Actually, that is a myth. There have been very few language changes in C++, and they are basically non-breaking. Most of the changes have been on a library level or as syntactical sugar.
That doesn't match my experience _at all_. Have you worked in C++ in a professional capacity?
There's a big update every 6 years, with a minor update every 6 years, but an update every 3 years.
 Last time I touched C++ (2015) people were _in some companies_ 
 starting to use C++11 (30% of it), because the compilers are 
 necessarily lagging behind the C++ comittee.
I think a big part of that was because of MSVC. They weren't C++11 compliant for a long time. Now you do have clang on Windows and I think even chrome/firefox use it as their compiler of choice on Windows instead of Microsoft's compiler. Back then there wasn't really any other C++ compiler on Windows worth using. Both clang/MSVC are kept up to date pretty quickly now.
Nov 24 2019
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 24 November 2019 at 15:30:10 UTC, Jab wrote:
 On Sunday, 24 November 2019 at 13:01:13 UTC, Guillaume Piolat 
 wrote:
 [...]
There's a big update every 6 years, with a minor update every 6 years, but an update every 3 years.
 [...]
I think a big part of that was because of MSVC. They weren't C++11 compliant for a long time. Now you do have clang on Windows and I think even chrome/firefox use it as their compiler of choice on Windows instead of Microsoft's compiler. Back then there wasn't really any other C++ compiler on Windows worth using. Both clang/MSVC are kept up to date pretty quickly now.
Other than Intel, PGI and Codegear.
Nov 24 2019
parent reply Jab <jab_293 gmall.com> writes:
On Sunday, 24 November 2019 at 17:54:56 UTC, Paulo Pinto wrote:
 On Sunday, 24 November 2019 at 15:30:10 UTC, Jab wrote:
 On Sunday, 24 November 2019 at 13:01:13 UTC, Guillaume Piolat 
 wrote:
 [...]
There's a big update every 6 years, with a minor update every 6 years, but an update every 3 years.
 [...]
I think a big part of that was because of MSVC. They weren't C++11 compliant for a long time. Now you do have clang on Windows and I think even chrome/firefox use it as their compiler of choice on Windows instead of Microsoft's compiler. Back then there wasn't really any other C++ compiler on Windows worth using. Both clang/MSVC are kept up to date pretty quickly now.
Other than Intel, PGI and Codegear.
Like I said, no other C++ compiler on Windows worth using.
Nov 24 2019
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 24 November 2019 at 23:18:29 UTC, Jab wrote:
 On Sunday, 24 November 2019 at 17:54:56 UTC, Paulo Pinto wrote:
 On Sunday, 24 November 2019 at 15:30:10 UTC, Jab wrote:
 [...]
Other than Intel, PGI and Codegear.
Like I said, no other C++ compiler on Windows worth using.
If one doesn't care about performance of generated code nor RAD tooling, naturally they aren't worth using.
Nov 24 2019
parent Jab <jab_293 gmall.com> writes:
On Monday, 25 November 2019 at 06:03:37 UTC, Paulo Pinto wrote:
 On Sunday, 24 November 2019 at 23:18:29 UTC, Jab wrote:
 On Sunday, 24 November 2019 at 17:54:56 UTC, Paulo Pinto wrote:
 On Sunday, 24 November 2019 at 15:30:10 UTC, Jab wrote:
 [...]
Other than Intel, PGI and Codegear.
Like I said, no other C++ compiler on Windows worth using.
nor RAD tooling, naturally they aren't worth using.
If you care about RAD, you're your using the wrong language never mind the compiler.
Nov 25 2019