www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Talk by Herb Sutter: Bridge to NewThingia

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
How to answer "why will yours succeed, when X, Y, and Z have failed?"

https://www.youtube.com/watch?v=wIHfaH9Kffs

Very insightful talk.
Jun 27
next sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu 
wrote:
 How to answer "why will yours succeed, when X, Y, and Z have 
 failed?"

 https://www.youtube.com/watch?v=wIHfaH9Kffs

 Very insightful talk.
He touches on, why we should have safe by default and the importance of the C++ call support. The challenges in this community is that everyone has their own market they would like to see D displace. C, C++, web, .Net, gnome gui...
Jun 28
prev sibling next sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu 
wrote:
 How to answer "why will yours succeed, when X, Y, and Z have 
 failed?"

 https://www.youtube.com/watch?v=wIHfaH9Kffs

 Very insightful talk.
To be honest the analysis doesn't quite stack up. Because compatibility is not the reason for the success of Go, or Rust. I would say the success of a language depends on many factors: * Luck * Timing - and a need to be filled * Sufficient commercial usage * Big name factor - Go authors tried a few times creating languages that did not succeed until they had Google backing. * Language offers something sufficiently different solution than existing solutions * Tooling * Quality of implementation
Jun 28
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote:
 On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu 
 wrote:
 How to answer "why will yours succeed, when X, Y, and Z have 
 failed?"

 https://www.youtube.com/watch?v=wIHfaH9Kffs

 Very insightful talk.
To be honest the analysis doesn't quite stack up. Because compatibility is not the reason for the success of Go, or Rust. I would say the success of a language depends on many factors: * Luck * Timing - and a need to be filled * Sufficient commercial usage * Big name factor - Go authors tried a few times creating languages that did not succeed until they had Google backing. * Language offers something sufficiently different solution than existing solutions * Tooling * Quality of implementation
* Community * Strong die hard advocate * Tutorials, learning resources Those are the stuff I personally think I can't contribute more.
Jun 28
parent aberba <karabutaworld gmail.com> writes:
On Monday, 29 June 2020 at 00:24:22 UTC, aberba wrote:
 On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar 
 wrote:
 [...]
* Community * Strong die hard advocate * Tutorials, learning resources Those are the stuff I personally think I can't contribute more.
I meant opposite, jeez 🙉 Those are the stuff I'm personally trying to push and contribute to for D primarily.
Jun 28
prev sibling next sibling parent welkam <wwwelkam gmail.com> writes:
On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote:

 To be honest the analysis doesn't quite stack up. Because 
 compatibility is not the reason for the success of Go, or Rust.

 I would say the success of a language depends on many factors:
Think of a reasons of why people are popular. Make a mental list of that. Now try to explain why Kardashians are still popular. Not everything in this life happens because of some good properties. At this moment Kardashians are popular because they are popular.
Jun 29
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote:
 To be honest the analysis doesn't quite stack up. Because 
 compatibility is not the reason for the success of Go, or Rust.
I think that's a misinterpretation of what was said. Compatibility is not a reason for success -- but the _absence_ of sufficient compatibility will always lead to failure. I can't speak for Go, but Rust's compatibility is clearly adequate given how Mozilla is able to fit it inside the (mostly C++) Firefox codebase.
Jul 02
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Thursday, 2 July 2020 at 10:21:19 UTC, Joseph Rushton Wakeling 
wrote:
 On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar 
 wrote:
 To be honest the analysis doesn't quite stack up. Because 
 compatibility is not the reason for the success of Go, or Rust.
I think that's a misinterpretation of what was said. Compatibility is not a reason for success -- but the _absence_ of sufficient compatibility will always lead to failure.
So why was Java successful? It was not compatible with an existing language. Neither Rust nor Go are compatible with C++. Rust, D and Go are all compatible with C in some sense. Basically Herb is claiming to succeed a language must be able to be a drop in replacement for C++ in a mix-match way. I think it is a fallacy. There is no single recipe that will make a language successful.
Jul 02
next sibling parent IGotD- <nise nise.com> writes:
On Thursday, 2 July 2020 at 18:22:54 UTC, Dibyendu Majumdar wrote:
 So why was Java successful? It was not compatible with an 
 existing language.
 Neither Rust nor Go are compatible with C++.
 Rust, D and Go are all compatible with C in some sense.

 Basically Herb is claiming to succeed a language must be able 
 to be a drop in replacement for C++ in a mix-match way. I think 
 it is a fallacy.

 There is no single recipe that will make a language successful.
It's funny nobody has mentioned ease of use. Why is Java so popular? I'd say it's easy to use among other things. Why is Python so popular? Because it is easy to use and many can quickly learn it. Why is C++ so popular? It is or at least has been easy to use in its domain, at least if you use it conservatively and do not dig too deep into its language features. Ease of use is a big factor.
Jul 02
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2020-07-02 at 18:22 +0000, Dibyendu Majumdar via Digitalmars-d-
announce wrote:
[=E2=80=A6]
 So why was Java successful? It was not compatible with an=20
 existing language.
Java has a weird history compared to other languages. It switched from whit= e goods programming language to browser programming language just at the mome= nt a large number of academics world wide were getting dissatisfied with Pascal/C/C++/Scheme/Miranda/OCaml as the set of languages to choose from to teach first year programming. It very rapidly failed as a browser language, but switched wonderfully quickly to be a virtual machine based general programming language. Timing is everything here=E2=80=A6 a large number of = academic jumped on the Java bandwagon, so a large number of undergraduates were forc= ed to learn it. There was a period in late 1990s and early 2000s when every CS graduate knew Java, and, to the eternal shame of academics, no other programming language. The second part of the success, at least in London, was the dissatisfaction= of many in the finance industry with Smalltalk. They saw Java, and the number = of Java programmers being produced by academic and switched to Java. The rest,= as they say, is history.
 Neither Rust nor Go are compatible with C++.
 Rust, D and Go are all compatible with C in some sense.
C is the portable assembly language of computing, any high level programmin= g language that cannot use C APIs is a dead language.
 Basically Herb is claiming to succeed a language must be able to=20
 be a drop in replacement for C++ in a mix-match way. I think it=20
 is a fallacy.
Herb does have a (not exactly) hidden agenda that C++ is the one true programming language.
 There is no single recipe that will make a language successful.
Very true. --=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
Jul 03
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu 
wrote:
 How to answer "why will yours succeed, when X, Y, and Z have 
 failed?"

 https://www.youtube.com/watch?v=wIHfaH9Kffs

 Very insightful talk.
Back to C++20 and beyond which Herb Sutter refers to a lot. Is C++20 a success, or even C++17? Does anyone know this? Modern C++ isn't a programming standard so what I've seen is just a mix of everything. I have lost track of all new C++ features and now he even refers it as "NewLang" what that is. Is that Bjarnes famous quote "Within C++, there is a much smaller and clearer language struggling to get out."? I believe it when I see it. One thing that isn't mention that is very important for a language to succeed is libraries. C++ has a lack of standard libraries which forces the programmer to look for third party alternatives, which are of varying standard. This leads to that the there is no particular programming API standard it must gravitate to the lowest common denominator. This in contrast to Phobos which is more complete. Does C++ need more language features or does C++ need better standard libraries? I would say the latter. If it weren't for Qt, C++ would just be a skeleton language. Qt is a great library and was that even before C++11 which proves that the new language features weren't that important. What do you think, did "modern C++" really succeed?
Jun 29
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2020-06-29 at 10:31 +0000, IGotD- via Digitalmars-d-announce wrote:
=20
[=E2=80=A6]
 Back to C++20 and beyond which Herb Sutter refers to a lot. Is=20
 C++20 a success, or even C++17? Does anyone know this? Modern C++=20
 isn't a programming standard so what I've seen is just a mix of=20
 everything.
I guess the question is whether concepts, coroutines, and modules finally m= ake it in. The really interesting question is whether metaclasses make C++23. Of course C++ is now really a niche language used by those who still use it and do not move on to more modern languages!
 I have lost track of all new C++ features and now he even refers=20
 it as "NewLang" what that is. Is that Bjarnes famous quote=20
 "Within C++, there is a much smaller and clearer language=20
 struggling to get out."? I believe it when I see it.
The problem is backward compatibility. Every new feature in C++ requires backward compatibility with all previous C++, leading to a more and more complex language. Fortran has the same problem but easier to cope with as i= t is a simpler language. Languages without standards do not have this problem= . Except when language developers introduce breaking changes and a section of the user population screams "we must have backward compatibility". What the= y mean really is that they do not want to maintain their code. The Java folk showed how this pans out: eventually companies that will not deal with breaking changes go bust and are no longer a problem. I am sure this will be seen as a rant and a troll, but that doesn't stop it also being true.
 One thing that isn't mention that is very important for a=20
 language to succeed is libraries. C++ has a lack of standard=20
 libraries which forces the programmer to look for third party=20
 alternatives, which are of varying standard. This leads to that=20
 the there is no particular programming API standard it must=20
 gravitate to the lowest common denominator. This in contrast to=20
 Phobos which is more complete.
Another rant=E2=80=A6 =E2=80=A6batteries included standard libraries are a thing of the 1990s and= earlier. They are a reflection of pre-Internet thinking. You got a language distribution, and everything else was home grown. Now we have the Internet you can get libraries via download. Languages come with the minimal library needed to function and all else is gettable. Go, Rust, Python, and other languages have this (even though Python still has a batteries included standard library). C++ has moved on to this idea; Conan = (or other system) hasn't really caught on in C++ circles. Ditto Fortran, still using pre-2000 thinking. D is in a similar position to Python, a huge batteries included standard library much of which should be culled, or at lease marked as deprecated, a= nd has an central package repository for people to use. Rust, Go, and Python, show the way here. Libraries can spring up, evolve, die off, all controlled= by usefulness to the user population. C++ people's focus on "the standard" see= ms to be stopping them doing good things.
 Does C++ need more language features or does C++ need better=20
 standard libraries? I would say the latter. If it weren't for Qt,=20
 C++ would just be a skeleton language. Qt is a great library and=20
 was that even before C++11 which proves that the new language=20
 features weren't that important.
=20
 What do you think, did "modern C++" really succeed?
Clearly Modern C++, aka C++11, was a great innovation and step forward. C++= 14, C++17, and I guess C++20 move the language forward. On the other hand people are stopping using C++ in favour of Go, Rust, Pyth= on, but it seems not D. --=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
Jun 29
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote:
 On Mon, 2020-06-29 at 10:31 +0000, IGotD- via 
 Digitalmars-d-announce wrote:
 
[…]
 Back to C++20 and beyond which Herb Sutter refers to a lot. Is 
 C++20 a success, or even C++17? Does anyone know this? Modern 
 C++ isn't a programming standard so what I've seen is just a 
 mix of everything.
I guess the question is whether concepts, coroutines, and modules finally make it in. The really interesting question is whether metaclasses make C++23.
Concepts, coroutines, and modules are already in ISO C++20. And co-routines are in a much better story than the incompatible runtimes currently existing for Rust async/await story.
 [...]

 On the other hand people are stopping using C++ in favour of 
 Go, Rust, Python, but it seems not D.
Rust still needs to improve a lot on its tooling and ecosystem to cover many of the scenarios we use C++ for, even if is safer. Already the fact that it lacks an ISO standard is a no go in many domains. I guess you mean using Python as glue for GPGU libraries written in C++.
Jun 29
parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2020-06-29 at 12:41 +0000, Paulo Pinto via Digitalmars-d-announce
wrote:
[=E2=80=A6]
=20
 Concepts, coroutines, and modules are already in ISO C++20.
Only once the standard is voted in. :-) Also ranges are in I believe.
 And co-routines are in a much better story than the incompatible=20
 runtimes currently existing for Rust async/await story.
I have not used C++ co-routines, but having used Rust co-routines, they see= m fine. You need to make good on your negative criticism =E2=80=93 which I wo= uld like to hear.
 Rust still needs to improve a lot on its tooling and ecosystem to=20
 cover many of the scenarios we use C++ for, even if is safer.
I can believe that may be true for others, but for me JetBrains CLion, Rust= up, and Cargo make for an excellent environment. crates.io works very well =E2= =80=93 better than CLion, CMake, and lots of manual hacking around to get librarie= s for C++.
 Already the fact that it lacks an ISO standard is a no go in many=20
 domains.
That is a choice for those organisations. I am guessing those organisations= do not use Java, D, Python, etc.
 I guess you mean using Python as glue for GPGU libraries written=20
 in C++.
In C, but yes. Though I haven't done it in a while now. --=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
Jun 29
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 29 June 2020 at 18:29:54 UTC, Russel Winder wrote:
 On Mon, 2020-06-29 at 12:41 +0000, Paulo Pinto via 
 Digitalmars-d-announce
 wrote:
 […]
 
 Concepts, coroutines, and modules are already in ISO C++20.
Only once the standard is voted in. :-) Also ranges are in I believe.
 And co-routines are in a much better story than the 
 incompatible runtimes currently existing for Rust async/await 
 story.
I have not used C++ co-routines, but having used Rust co-routines, they seem fine. You need to make good on your negative criticism – which I would like to hear.
Rust has only standardized part of the async/await story, the asynchronous runtime is not part of the standard library, so currently it is impossible to write code that works flawlessly across the existing runtimes. https://stjepang.github.io/2020/04/03/why-im-building-a-new-async-runtime.html Additionally there are still rough edges with lifetimes across async/await calls.
 Rust still needs to improve a lot on its tooling and ecosystem 
 to cover many of the scenarios we use C++ for, even if is 
 safer.
I can believe that may be true for others, but for me JetBrains CLion, Rustup, and Cargo make for an excellent environment. crates.io works very well – better than CLion, CMake, and lots of manual hacking around to get libraries for C++.
The typical scenarios where we would use GPGPU shaders, iDevices, Android and Windows drivers, Arduino, SYCL, DPC++, Unreal, XBox/PS/Switch SDKs, ...
 Already the fact that it lacks an ISO standard is a no go in 
 many domains.
That is a choice for those organisations. I am guessing those organisations do not use Java, D, Python, etc.
Java has a standard to guide for, updated for each language release. So it doesn't need to be ISO, can be ECMA, or some other formal writen specification, with multiple vendor implementations.
 I guess you mean using Python as glue for GPGU libraries 
 written in C++.
In C, but yes. Though I haven't done it in a while now.
Jun 29
parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2020-06-29 at 20:41 +0000, Paulo Pinto via Digitalmars-d-announce
wrote:
[=E2=80=A6]
=20
 Rust has only standardized part of the async/await story, the=20
 asynchronous
 runtime is not part of the standard library, so currently it is=20
 impossible to write code that works flawlessly across the=20
 existing runtimes.
[=E2=80=A6] Actually this is a good thing in that I can write Rust async/await code and have it run on the GTK event loop. Here we have a case of multiple vendor implementations of a single standard interface. The problems tend to be in = the implementations of the event loops not the bit that is effectively (de fact= o rather than de jure) standardised. [=E2=80=A6]
 The typical scenarios where we would use GPGPU shaders, iDevices,=20
 Android and Windows drivers, Arduino, SYCL, DPC++, Unreal,=20
 XBox/PS/Switch SDKs, ...
Not my area, but my guess is that there is sufficient pre-existing code bas= e that it is not feasible to switch languages, staying with the languages of = the pre-existing codebase is the sensible thing to do unless someone comes alon= g with a big pot of money. =20 [=E2=80=A6]
 Java has a standard to guide for, updated for each language=20
 release.
=20
 So it doesn't need to be ISO, can be ECMA, or some other formal=20
 writen  specification, with multiple vendor implementations.
Java is really standardised by the implementaion of OpenJDK. There is no standard agreed by any formal body other than the JCP executive committee. There are three maybe four implementations, the one everyone uses, and the other you have to pay for. --=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
Jul 01
prev sibling next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote:
 On Mon, 2020-06-29 at 10:31 +0000, IGotD- via 
 Digitalmars-d-announce wrote:
 Another rant…

 …batteries included standard libraries are a thing of the 1990s 
 and earlier. They are a reflection of pre-Internet thinking. 
 You got a language distribution, and everything else was home 
 grown.

 Now we have the Internet you can get libraries via download. 
 Languages come with the minimal library needed to function and 
 all else is gettable. Go, Rust, Python, and other languages 
 have this (even though Python still has a batteries included 
 standard library). C++ has moved on to this idea; Conan (or 
 other system) hasn't really caught on in C++ circles. Ditto 
 Fortran, still using pre-2000 thinking.
And that is completely wrong headed. Internet is not always directly accessible. There are a lot of companies that restrict access to the Internet for their security sensible servers, intranets etc. University people often have no clue what is standard in the corporate or the public office world. To give an example from the EU Commission. A good portion of our servers are isolated on an Intranet with very restricted access to the Internet via proxys for which access has to be requested for to the IT service. Out Intranet is deployed over different sites in Europe but the trafic is not routed over the Internet but over specialized network reserved for public institutions in Europe. The few bridges to the Internet in that network are surveilled like Fort Knox. There are also special rooms throughout our premises that are not even connected to the Intranet. Building software for these special machines has become a real challenge nowadays. These security issues are not even the strictest I've seen or heard of here in Luxembourg with all its banking companies. No, Internet is not always as easy peasy and having a language that can live alone and provide quite a lot of features without always calling home is a good thing. That's why I always ranted several versions ago when Visual Studio was nearly forced upon the user. Visual Studio and all Microsoft stuff is extremely difficult to install with a poor Internet connection (the setup didn't even accept a proxy). Sorry, my rant.
Jun 29
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 29 June 2020 at 15:44:38 UTC, Patrick Schluter wrote:
 [snip]

 And that is completely wrong headed.
+1 As much as I'm sympathetic to the arguments for a slim standard library, the amount of problems I've had in a corporate setting trying to get libraries installed behind firewalls/proxies makes me glad for the larger one. Until a few years ago, I had to manually download every R library and every single one of their dependencies and manage them myself. It's one reason I really like run.dlang.org. I've never had a problem with it. Of course, I see nothing wrong with a high bar for entry into the standard library or the sort of promotion/relegation-type approach I've heard on the forums.
Jun 29
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 29 June 2020 at 16:47:27 UTC, jmh530 wrote:
 On Monday, 29 June 2020 at 15:44:38 UTC, Patrick Schluter wrote:
 [snip]

 And that is completely wrong headed.
+1 As much as I'm sympathetic to the arguments for a slim standard library, the amount of problems I've had in a corporate setting trying to get libraries installed behind firewalls/proxies makes me glad for the larger one. Until a few years ago, I had to manually download every R library and every single one of their dependencies and manage them myself. It's one reason I really like run.dlang.org. I've never had a problem with it. Of course, I see nothing wrong with a high bar for entry into the standard library or the sort of promotion/relegation-type approach I've heard on the forums.
All packages I install on our Linux servers, I have to compile them by source. All the default paths used by the packages are readonly. So, everything with prefix, all dependencies. The machine with an outdated gcc (4.4.7). In that configuration, it is impossible to build a recent dmd. Fortunately I managed to get an alternative proxy access that managed to download the bootstrap d compiler.
Jun 29
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2020-06-29 at 15:44 +0000, Patrick Schluter via Digitalmars-d-annou=
nce=20
wrote:
=20
[=E2=80=A6]
 And that is completely wrong headed. Internet is not always=20
 directly accessible. There are a lot of companies that restrict=20
 access to the Internet for their security sensible servers,=20
=20
[=E2=80=A6]
 No, Internet is not always as easy peasy and having a language=20
 that can live alone and provide quite a lot of features without=20
 always calling home is a good thing.
=20
[=E2=80=A6] So that is Java out then as a language to use for corporate software development activity. Way back when I was running a company or two, I put in place "you can't acc= ess the internet directly for dependencies" system, more to lower bandwidth use than security it has to be said. So we bought another disc and mirrored the repository =E2=80=93 but not slavishly, just the bits we needed and with va= rious scans and tests to try and stop any rogue software. This seemed to be the standar= d sort of behaviour back then. Perhaps this is not what happens now? --=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
Jul 01
prev sibling next sibling parent reply Dagmar <dagmar.zorg gmail.com> writes:
On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote:
 Of course C++ is now really a niche language used by those who 
 still use it and do not move on to more modern languages!
I am a C++ developer. I do want to move to a modern language, but there is no one that fits my needs. Rust has a very promising ownership-borrowing concept but the lack of OOP and its awful syntax (mostly because of lifetimes) make it a no go for me. Go is just an oversimplified language. No generics/teplates in 2020, seriously? D has a GC. If you turn it off you lose dynamic/associative arrays, classes, probably something else. Why would I even want to use such language at all? It's much easier to stay with C++ this way, since it has lots of C/C++ libraries, IDEs, tools, broad community, support of big companies.
 The problem is backward compatibility. Every new feature in C++ 
 requires backward compatibility with all previous C++, leading 
 to a more and more complex language.
Totally agree. It would be much better if C++ was redesigned from scratch, dropping backward compatibility and making things better: explicit constructors/operators by default, default-initialized variables, const by default, and maybe even move semantics by default. You can explicitly copy an object if you want, but only when you really need it. We don't need 3 ways of initialization, lots of different reference types, implicit casts between different integer types, interpreting arrays as pointers, etc.
 Clearly Modern C++, aka C++11, was a great innovation and step 
 forward. C++14, C++17, and I guess C++20 move the language 
 forward.
C++20 is a big improvement at least because of concepts, coroutines, and ranges.
 On the other hand people are stopping using C++ in favour of 
 Go, Rust, Python, but it seems not D.
Of course, since D doesn't look like a mature language. I've been following it for many years and it doesn't really improve. It looks just like a bunch of different things/concepts put together. Many things are stalled without of any progress because there is no consensus. The entire DIP process is not good. There is no way to find the current DIP status, no way to learn when and whether it's going to be implemented or not. Have you noticed such questions in the forum recently? The current status of the language is unclear. Sometimes there is only one way to find out why it behaves like it does: to ask in this forum. And you may not like the answers. D has transitive const, but what if I should lazy evaluate/cache a value or use a mutex? If I shouldn't use const, how should I emphasize the intention to pass a pointer only for reading? How can I be sure that my class invariant is not compromised? Also, there is the shared attribute, but it isn't designed nor implemented well. Lots of questions, no solutions. D is intended to be a C++ replacement, but it doesn't explain to C++ programmers how to change their way of thinking. I'd appreciate if there was a document that explains typical tasks and ways to get them done in D for the C++ dummies, like me. Maintainers don't like to make breaking changes when they are required. Come on guys, it's called an evolution. That's why C++ is so overcomplicated right now. It tries to keep backward compatibility at all costs. I hope you don't want D to get into the same situation? Any modern language requires a chance to evolve. Sometimes you just have to break something. And making it once in a year (or 2-3 years) doesn't look like a bad option to me.
Jun 29
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote:
 D has a GC. If you turn it off you lose dynamic/associative 
 arrays, classes, probably something else.
You just have to construct them with a function instead of with the built-in `new` operator. (Well, associative array will need a library solution picked too, but the rest work build in if you construct them differently.) It is very easy to do, just perhaps not well documented.
Jun 29
parent aberba <karabutaworld gmail.com> writes:
On Monday, 29 June 2020 at 15:54:36 UTC, Adam D. Ruppe wrote:
 On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote:
 D has a GC. If you turn it off you lose dynamic/associative 
 arrays, classes, probably something else.
You just have to construct them with a function instead of with the built-in `new` operator. (Well, associative array will need a library solution picked too, but the rest work build in if you construct them differently.) It is very easy to do, just perhaps not well documented.
Ditto. Hence the need for documenting them.
Jun 30
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 6/29/20 8:45 AM, Dagmar wrote:

 I am a C++ developer.
I used to be a C++ developer; luckily, I primarily write in D these days. (I can still code in C++ and will have to do so again soon.)
 I do want to move to a modern language, but there
 is no one that fits my needs.
[...]
 Go is just an oversimplified language. No generics/teplates in 2020,
 seriously?
+1 And it's fascinating how they sold all the shortcomings as benefits. Amazing!
 D has a GC.
Coming from C++, I was a die-hard "deterministic destruction" guy and it took me a long time to embrace GC. Now I know GC is pure help. GC is no more issue than any other engineering decisions.
 If you turn it off you lose dynamic/associative arrays,
 classes, probably something else.
Then don't turn it off. :) I understand there are programs where an undeterministic delay in processing is unacceptable but those programs all run on real-time operating systems anyway, right? ;)
 Why would I even want to use such
 language at all?
For practicality. For getting things done.
 It's much easier to stay with C++ this way, since it
 has lots of C/C++ libraries, IDEs, tools, broad community, support of
 big companies.
It requires a strong C++ mindset to take GC as a liability and accept C++ complexities like the following one as manageable: OOPS: :) I fail to find a reference table that explains implicitly or explicitly deleted or defaulted fundamental C++ operations like the copy constructor. Yeah, accepting that kind of complexity but rejecting the GC is interesting. (I am not directing this to you but to most C++ programmers.)
 Of course, since D doesn't look like a mature language. I've been
 following it for many years and it doesn't really improve. It looks just
 like a bunch of different things/concepts put together.
That may be true for many languages but when it comes to getting things done I find D much more productive, manageable, easier, etc. etc. compared to C++. C++ has only one thing over D: Many smart people are already using C++.
 Many things are
 stalled without of any progress because there is no consensus.
 The entire DIP process is not good. There is no way to find the current
 DIP status, no way to learn when and whether it's going to be
 implemented or not. Have you noticed such questions in the forum 
recently?
 The current status of the language is unclear. Sometimes there is only
 one way to find out why it behaves like it does: to ask in this forum.
 And you may not like the answers.
 D has transitive const, but what if I
 should lazy evaluate/cache a value or use a mutex?
Although I agree that transitive const is the correct feature, I too find it difficult.
 If I shouldn't use
 const, how should I emphasize the intention to pass a pointer only for
 reading? How can I be sure that my class invariant is not compromised?
 Also, there is the shared attribute, but it isn't designed nor
 implemented well. Lots of questions, no solutions. D is intended to be a
 C++ replacement, but it doesn't explain to C++ programmers how to change
 their way of thinking.
There is this dated document: https://dlang.org/articles/cpptod.html Although dated, that document should be sufficient to jump to D from C++. :)
 Maintainers don't like to make breaking changes when they are required.
 Come on guys, it's called an evolution.
Interestingly, one of the criticism D gets is how it evolves with breaking changes. :)
 That's why C++ is so
 overcomplicated right now. It tries to keep backward compatibility at
 all costs. I hope you don't want D to get into the same situation? Any
 modern language requires a chance to evolve. Sometimes you just have to
 break something. And making it once in a year (or 2-3 years) doesn't
 look like a bad option to me.
I agree. Ali
Jun 29
next sibling parent aberba <karabutaworld gmail.com> writes:
On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote:
 On 6/29/20 8:45 AM, Dagmar wrote:
 If I shouldn't use
 const, how should I emphasize the intention to pass a pointer
only for
 reading? How can I be sure that my class invariant is not
compromised?
 Also, there is the shared attribute, but it isn't designed nor
 implemented well. Lots of questions, no solutions. D is
intended to be a
 C++ replacement, but it doesn't explain to C++ programmers
how to change
 their way of thinking.
There is this dated document:
  https://dlang.org/articles/cpptod.html
Ali, how you answered the questions is how I think one would want to find a document for C++ folks moving to D. The outdated doc I believed focused mostly on the syntactic differences which I agree we now need someone to help get it up to date with more coverage. But a document with answers to common practical questions like just liked the above... const, shared, GC, etc doesn't seem to fit in the that doc. I believe you've pretty much said some things that we can work on to get things documented. I'm sure there's more similar questions. So a D-idioms-like kind of doc/wiki might do. Of course, in addition to the cpptod.html one. https://p0nce.github.io/d-idioms/
Jun 30
prev sibling parent reply Dagmar <dagmar.zorg gmail.com> writes:
On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote:
 Then don't turn it off. :)

 I understand there are programs where an undeterministic delay 
 in processing is unacceptable but those programs all run on 
 real-time operating systems anyway, right? ;)
I'm working on virtual audio instruments and effect processors and they do their job in real-time. GC is luxury in this context. If I switched to D, I'd have to also switch from OOP to simple C-like structured programming and implement my own basic set of algorithms and data structures.
 OOPS: :) I fail to find a reference table that explains 
 implicitly or explicitly deleted or defaulted fundamental C++ 
 operations like the copy constructor.
I agree, C++ is overcomplicated. That's the reason why I look at other languages.
 Yeah, accepting that kind of complexity but rejecting the GC is 
 interesting. (I am not directing this to you but to most C++ 
 programmers.)
Not manual memory management is the main problem in modern C++, but its excessive complexity with thousands of nuances that simply do not allow you to write a program without hidden issues. TBH, I don't suffer bc I have to deal with memory management at all. I understand the point of GC advocates, but among other things, people choose C++ because it gives them more control. A good language should provide the ability to easily ADD a garbage collector, not the ability to cut it off, losing a half of the language features and its standard library.
 That may be true for many languages but when it comes to 
 getting things done I find D much more productive, manageable, 
 easier, etc. etc. compared to C++. C++ has only one thing over 
 D: Many smart people are already using C++.
D has lots of really interesting features and it's more productive than C++, but I find it hard to use in real projects.
 Although I agree that transitive const is the correct feature, 
 I too find it difficult.
Well, I agree that transitive const is a good feature for some use cases. For instance, a function may return a pointer to a constant linked-list node. In the case of non-transitive const you can reach and modify other list nodes through this "constant" pointer, which is not good at all. But introducing transitive const without showing a way to implement caching, using mutexes, etc is not a good idea either. Imagine a class, that protects its data with a mutex. How should I implement a getter function (const) that locks the mutex? The only way that comes into my mind is introducing a global mutex-manager entity that works with mutex handles (integers). Any class that requires a mutex would call this manager to create a new mutex and remembers its handle. This way it can pass this handle to the manager when the mutex should be locked/unlocked. But obviously, this is such a horrible scheme.
 There is this dated document:

   https://dlang.org/articles/cpptod.html

 Although dated, that document should be sufficient to jump to D 
 from C++. :)
Not at all. It's not so hard to learn the syntax and other details of a new language. It's hard to adopt it to my needs. This document tells nothing about typical issues that C++ programmers encounter with when trying to do a real work with D.
Jul 02
parent reply claptrap <clap trap.com> writes:
On Thursday, 2 July 2020 at 10:13:02 UTC, Dagmar wrote:
 On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote:
 Then don't turn it off. :)

 I understand there are programs where an undeterministic delay 
 in processing is unacceptable but those programs all run on 
 real-time operating systems anyway, right? ;)
I'm working on virtual audio instruments and effect processors and they do their job in real-time. GC is luxury in this context. If I switched to D, I'd have to also switch from OOP to simple C-like structured programming and implement my own basic set of algorithms and data structures.
If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. This can be mechanically checked by the compiler with the nogc attribute. The point is even in C++ you should never ever do malloc/free in the audio thread, you might get away with it under low CPU load, but if you're running at high load it can barf the audio. So GC is just a variation on the same problem. Dont call malloc/free, dont use GC in anyway. You also have to make sure that the GC knows about your pointers, so if you have a pointer to something, make sure it's reachable from stuff the GC will scan. If it exists only on the stack in the audio thread the GC could collect it as it wont know it is still in use. Also see this... https://github.com/AuburnSounds/Dplug
Jul 02
next sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
 If you're doing a plugin the host callback thread wont be known 
 to the D runtime and so the GC wont pause it. So as long as you 
 dont call anything that might trigger the GC while in the 
 callback you wont get GC pauses affecting the audio rendering. 
 This can be mechanically checked by the compiler with the  nogc 
 attribute.

 The point is even in C++ you should never ever do malloc/free 
 in the audio thread, you might get away with it under low CPU 
 load, but if you're running at high load it can barf the audio. 
 So GC is just a variation on the same problem. Dont call 
 malloc/free, dont use GC in anyway.

 You also have to make sure that the GC knows about your 
 pointers, so if you have a pointer to something, make sure it's 
 reachable from stuff the GC will scan. If it exists only on the 
 stack in the audio thread the GC could collect it as it wont 
 know it is still in use.

 Also see this...

 https://github.com/AuburnSounds/Dplug
I think you can make a callback thread to D work if you have a trampoline function and then call thread_attachThis rt_moduleTlsCtor before calling the actual callback. Then the thread will be known to D runtime.
Jul 02
parent claptrap <clap trap.com> writes:
On Thursday, 2 July 2020 at 12:36:09 UTC, IGotD- wrote:
 On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
 If you're doing a plugin the host callback thread wont be 
 known to the D runtime and so the GC wont pause it. So as long 
 as you dont call anything that might trigger the GC while in 
 the callback you wont get GC pauses affecting the audio 
 rendering. This can be mechanically checked by the compiler 
 with the  nogc attribute.

 The point is even in C++ you should never ever do malloc/free 
 in the audio thread, you might get away with it under low CPU 
 load, but if you're running at high load it can barf the 
 audio. So GC is just a variation on the same problem. Dont 
 call malloc/free, dont use GC in anyway.

 You also have to make sure that the GC knows about your 
 pointers, so if you have a pointer to something, make sure 
 it's reachable from stuff the GC will scan. If it exists only 
 on the stack in the audio thread the GC could collect it as it 
 wont know it is still in use.

 Also see this...

 https://github.com/AuburnSounds/Dplug
I think you can make a callback thread to D work if you have a trampoline function and then call thread_attachThis rt_moduleTlsCtor before calling the actual callback. Then the thread will be known to D runtime.
Sorry maybe I was unclear, I'm saying keep the real time thread hidden from D runtime & GC. Just make sure any GC memory referenced by the real time thread is also referenced in the threads/data that is known about by the runtime / GC. Or only pass the real time threa malloced memory.
Jul 02
prev sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
 I'm working on virtual audio instruments and effect processors 
 and they do their job in real-time. GC is luxury in this 
 context. If I switched to D, I'd have to also switch from OOP 
 to simple C-like structured programming and implement my own 
 basic set of algorithms and data structures.
I work in audio effects, use no GC, and use OOP since TypeInfo is there. You are right about basic set of algorithm and data structure.
 If you're doing a plugin the host callback thread wont be known 
 to the D runtime and so the GC wont pause it. So as long as you 
 dont call anything that might trigger the GC while in the 
 callback you wont get GC pauses affecting the audio rendering.
That was how we did it for a while, the speed hit was immeasurable. Generally, if a callback thread can own GC things, it needs to be registered and deregistered at exit. The problem with the D runtime can be (depends on when): - macOS compat in a shared lib - D host hosting D client can be tricky
 The point is even in C++ you should never ever do malloc/free 
 in the audio thread
Pet peeve, lot of practical audio applications do this (at startup) :) You'll find mutexes in the audio thread in the most well known audio frameworks... all of them since spinlocks-style algorithms have worse worse-cases. If the event is rare enough, it won't really matter and chasing it would be a lot of effort just to stay holier. But it's a good talk topic so regularly people will berate other about how it's a bad thing.
 Also see this...

 https://github.com/AuburnSounds/Dplug
Note that we disabled the runtime (and GC) for reasons I cannot entirely collected, we've tried to enable it back several times and it's hard. D is very fitting for audio.
Jul 02
parent claptrap <clap trap.com> writes:
On Thursday, 2 July 2020 at 13:03:12 UTC, Guillaume Piolat wrote:
 On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
 If you're doing a plugin the host callback thread wont be 
 known to the D runtime and so the GC wont pause it. So as long 
 as you dont call anything that might trigger the GC while in 
 the callback you wont get GC pauses affecting the audio 
 rendering.
That was how we did it for a while, the speed hit was immeasurable. Generally, if a callback thread can own GC things, it needs to be registered and deregistered at exit.
I think my post was unclear, I'm saying keep the realtime thread hidden, just make sure any references are either duplicated somewhere reachable by the GC, or only give the real time thread malloced memory. Chances are almost all the memory the audio thread has references to will be referenced elsewhere anyway. And those that arnt, say a message object passed through a queue, just use malloced memory.
Jul 02
prev sibling next sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote:
 D has a GC. If you turn it off you lose dynamic/associative 
 arrays, classes, probably something else.
This is the outside perception of the way things are. In reality you can actually disable the GC and still use: - classes - associative arrays (dplug:core) - dynamic arrays if you manage their lifetime So discarding D because it has a GC is an unfortunate common idea, that isn't really confirmed by experience: none of industrial users have had intractable problems with it.7 If anything, a GC is a global owner that can avoid some copies, hence... allocation.
Jun 29
parent reply IGotD- <nise nise.com> writes:
On Monday, 29 June 2020 at 22:23:57 UTC, Guillaume Piolat wrote:
 In reality you can actually disable the GC and still use:
 - classes
 - associative arrays (dplug:core)
 - dynamic arrays if you manage their lifetime
Honestly, a guide how to do this would be very helpful. I'm particularly interested in how managing the lifetime of dynamic arrays in order to avoid GC means in practice, or are you referring to "dynamic arrays" as slices?
Jun 29
parent Guillaume Piolat <first.name gmail.com> writes:
On Monday, 29 June 2020 at 22:44:51 UTC, IGotD- wrote:
 On Monday, 29 June 2020 at 22:23:57 UTC, Guillaume Piolat wrote:
 In reality you can actually disable the GC and still use:
 - classes
 - associative arrays (dplug:core)
 - dynamic arrays if you manage their lifetime
Honestly, a guide how to do this would be very helpful.
Yes, the answers are complex but I think it could be recap in a nice table (features vs level of GC avoidance).
Jun 29
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote:

 Sometimes there is only one way to find out why it behaves like 
 it does: to ask in this forum. And you may not like the 
 answers. D has transitive const, but what if I should lazy 
 evaluate/cache a value or use a mutex? If I shouldn't use 
 const, how should I emphasize the intention to pass a pointer 
 only for reading? How can I be sure that my class invariant is 
 not compromised? Also, there is the shared attribute, but it 
 isn't designed nor implemented well. Lots of questions, no 
 solutions. D is intended to be a C++ replacement, but it 
 doesn't explain to C++ programmers how to change their way of 
 thinking. I'd appreciate if there was a document that explains 
 typical tasks and ways to get them done in D for the C++ 
 dummies, like me.
This calls for a D-idioms for C++ folks. Its overlooked but I believe its very important to have. Folks who know the language might overlook this but can be of great help for new recruits. Considering that's the goal...at least my goal :) It requires someone with C++ knowledge to start, then we'll take care of driving in more idioms. Like a GitHub wiki or something. The D wiki more appropriately for centralization. Anyone up for it?
Jun 30
parent Guillaume Piolat <first.name gmail.com> writes:
On Tuesday, 30 June 2020 at 11:12:22 UTC, aberba wrote:
 It requires someone with C++ knowledge to start, then we'll 
 take care of driving in more idioms. Like a GitHub wiki or 
 something. The D wiki more appropriately for centralization.

 Anyone up for it?
D and C++ are VERY different languages: - D objects have different construction sequences and teardown sequences. In C++ when you can name an object you are guaranteed it is constructed. Not in D. - the meta-game of C++ meta-programming was template specialization for a long time, and is considered hard and something to avoid. For D it has been CTFE + string mixins for a long time, and is considered only moderately difficult. - D uses DUB, modern dependency management that can make you maintain a lot more programs that you thought possible ^^. C++ culture is pretty much again this convenience. - T.init is a valid D object, D destructors must handle T.init. - destructor of heap objects is a big trap in D, perhaps the biggest surprise when coming from C++ - D collections do not necessarily own their elements, and are generally less complete than C++ collecions. - D always has RTTI and Exceptions - the C++ culture is much more conservative since regular people that wanted some modicum of sanity have fled to - mixed ownership (GC + manual) is more complicated than just scoped ownership; but ultimately liberating, and fast. - ...so you have to actually know how the GC work.
Jul 02
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2020-06-29 at 15:45 +0000, Dagmar via Digitalmars-d-announce wrote:
 On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote:
 Of course C++ is now really a niche language used by those who=20
 still use it and do not move on to more modern languages!
=20 I am a C++ developer. I do want to move to a modern language, but=20 there is no one that fits my needs.
So stick with C++? Changing language is not always the right choice. But it= is a very context dependent decision.
 Rust has a very promising ownership-borrowing concept but the=20
 lack of OOP and its awful syntax (mostly because of lifetimes)=20
 make it a no go for me.
In the classic terminology, Rust is object based not object oriented. The question is whether inheritance is crucial for the application. Clearly inheritance is crucial to GTK, so the gtk-rs folk have created an inheritan= ce system in Rust. In my experience, unless you are writing a library type, if your code has lifetime variables then "you are doing it wrong". As soon as I stopped tryi= ng to use any lifetime variables in my Rust applications it all got a lot easi= er. Of course for library code that has to worry about lifetimes, they are need= ed.
 Go is just an oversimplified language. No generics/teplates in=20
 2020, seriously?
Actually the Go core team are very serious about not having generics in Go. Despite the plethora of proposals, none have really made it. I do wonder if often the objections to a proposal are more along the lines of "we didn't think of that so it is not going in". I think there will eventually be generics in Go, but I have no idea when. T= o be open, I have stopped using Go. Not so much because of the language, but because the GTK and GStreamer bindings are somewhat second rate.
 D has a GC. If you turn it off you lose dynamic/associative=20
 arrays, classes, probably something else. Why would I even want=20
 to use such language at all? It's much easier to stay with C++=20
 this way, since it has lots of C/C++ libraries, IDEs, tools,=20
 broad community, support of big companies.
Or use Rust. ;-) [=E2=80=A6]
 C++20 is a big improvement at least because of concepts,=20
 coroutines, and ranges.
I can't say I will be tempted back to C++, the GTK and GStreamer bindings a= re a bit second rate. Having got into D and Rust for doing my desktop applications, I am not going back. [=E2=80=A6] --=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
Jul 03
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote:
 On Mon, 2020-06-29 at 10:31 +0000, IGotD- via 
 Digitalmars-d-announce wrote:
 
On the other hand people are stopping using C++ in favour of Go, Rust, Python, but it seems not D.
This isn't a fact by the way, there are many people using D, including folks I never expected. We could use more PR though. In D's case, its PR, its what I'm looking to do something about.
Jun 30
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 29 June 2020 at 10:31:43 UTC, IGotD- wrote:
 On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu 
 wrote:
 How to answer "why will yours succeed, when X, Y, and Z have 
 failed?"

 https://www.youtube.com/watch?v=wIHfaH9Kffs

 Very insightful talk.
Back to C++20 and beyond which Herb Sutter refers to a lot. Is C++20 a success, or even C++17? Does anyone know this? Modern C++ isn't a programming standard so what I've seen is just a mix of everything. I have lost track of all new C++ features and now he even refers it as "NewLang" what that is. Is that Bjarnes famous quote "Within C++, there is a much smaller and clearer language struggling to get out."? I believe it when I see it. One thing that isn't mention that is very important for a language to succeed is libraries. C++ has a lack of standard libraries which forces the programmer to look for third party alternatives, which are of varying standard. This leads to that the there is no particular programming API standard it must gravitate to the lowest common denominator. This in contrast to Phobos which is more complete. Does C++ need more language features or does C++ need better standard libraries? I would say the latter. If it weren't for Qt, C++ would just be a skeleton language. Qt is a great library and was that even before C++11 which proves that the new language features weren't that important. What do you think, did "modern C++" really succeed?
Yes it did, thanks to its rejuvenation and CUDA, C++ has become the main language in HPC and ML, NVidia now designs their GPUs having C++ semantics in mind, although CUDA is designed as language agnostic GPGPU environment. Metal Shaders and HLSL are largely based on C++14, and due to the game developers pressure, Google and Samsung have taken the effort to make HLSL available on Vulkan as well, porting Microsoft's open sourced HLSL compiler to SPIR-V.. On Windows, the Windows team is quite keen pushing C++/WinRT (based on C++17) to eventually provide a .NET like experience while using C++/WinUI, although the Visual Studio tooling is still lacking. Unreal is already supporting C++17 and GCC is discussing moving to C++17 as default dialect. Apple, Google, Microsoft, Nintendo, Sony, NVidia, AMD, ARM, still have lots of plans for it, even if they also own other language stacks on their SDKs. So, even those of us that rather spend our productive time in other stacks, occasionally dealing with C++ is unavoidable, and it continue being so for the decades to come. Which is why good C++ compatibility is a very valuable sales pitch of any language. For D, on Windows that would mean to improve COM support to deal with UWP as well, as it is COM vNext. Project Reunion plans
Jun 29
prev sibling next sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu 
wrote:
 How to answer "why will yours succeed, when X, Y, and Z have 
 failed?"

 https://www.youtube.com/watch?v=wIHfaH9Kffs

 Very insightful talk.
Herb Sutter is a national treasure, C++ has become bearable, nay even useful, under his stewardship and that is really saying something....
Jul 02
parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2020-07-02 at 13:28 +0000, Abdulhaq via Digitalmars-d-announce wrot=
e:
=20
[=E2=80=A6]
 Herb Sutter is a national treasure, C++ has become bearable, nay=20
 even useful, under his stewardship and that is really saying=20
 something....
s/national/international/ Herb's closing keynote at ACCU 2017 was a joy to be in, even as a C++ disliker. The energy he generated in the mostly pro-C++ audience was astounding. https://www.youtube.com/watch?v=3D6nsyX37nsRs&list=3DPL9hrFapz4dsMQuBQTnHXo= gJpMj6L_EQ10 I should add the questions went on for over an hour after the talk. I only brought it to an end so that people could go home =E2=80=93 and the hotel a= nd A/V staff could clear up. Even then Herb was another 20 or 30 minutes answering further questions as the room around them was disassembled. =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
Jul 03
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu 
wrote:
 How to answer "why will yours succeed, when X, Y, and Z have 
 failed?"

 https://www.youtube.com/watch?v=wIHfaH9Kffs

 Very insightful talk.
Great talk. Similar to what I was trying to say in my DConf19 talk but in many ways better.
Jul 02