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