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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020