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.
