Experimental Support For C++20 Coroutines Has Landed In GCC 10

[phoronix]

Phoronix: Experimental Support For C++20 Coroutines Has Landed In GCC 10

As of this morning experimental support for C++20 coroutines has been merged into the GCC 10 compiler!..

http://www.phoronix.com/scan.php?pag...outines-GCC-10

[elatllat]

Time to trash it and use rust instead yet?

[bachchain]

Maybe I missed something, but the spec doesn't really say anything about the executor. Is it implicit, like with JavaScript?

[uid313]

Time to trash it and use rust instead yet?

Or maybe this is an evolution in the design of C++ which has allowed it to catch up with Rust, or at least be improved to the point that it is "good enough" and that even if Rust is better, it is not enough better.

I wonder how Rust compares to C++. I think Rust have better type safety, better null handling, and a head start on coroutines, it also have package management via Cargo.

[clavko]

Time to trash it and use rust instead yet?

Hardly - there are vast areas of programming with billions of dollars of investment barely moving out moved to C++11. Obviously, advanced features such as modules, coroutines, concepts and pals do not bear much significance to those. It's not going to die anytime soon (as in decades).

The being said - Rust is a great contender and I hope it keeps improving and evolving. There are couple of venues which might not deliver this outcome, though - think Ruby slow death style, or HipHop VM learnings backport to PHP, Microsoft overrunning it with Pony or something similar, Mozilla closing before taking Rust to critical mass...

All of that has nothing to do with the Rust technical design which seems rather well thought to me.

[Redfoxmoon]

Or maybe this is an evolution in the design of C++ which has allowed it to catch up with Rust, or at least be improved to the point that it is "good enough" and that even if Rust is better, it is not enough better.

I wonder how Rust compares to C++. I think Rust have better type safety, better null handling, and a head start on coroutines, it also have package management via Cargo.

Language package managers is an anti-feature.

[uid313]

Language package managers is an anti-feature.

Why?
Package managers are awesome. If something isn't supported by the standard library, how else am I going to get that functionality? Go on some random website and download a ZIP file that then gets outdated?

[Almindor]

Or maybe this is an evolution in the design of C++ which has allowed it to catch up with Rust, or at least be improved to the point that it is "good enough" and that even if Rust is better, it is not enough better.

I wonder how Rust compares to C++. I think Rust have better type safety, better null handling, and a head start on coroutines, it also have package management via Cargo.

Rust is miles ahead of C++ when it comes to "correctness". Proper move semantics, all the things you mentioned and more. I don't think C++ can get to Rust's position without removing support for ... C++.

Rust also provides the compiler with more optimization options because of immutability by default, aliasing rules and more. It has its own set of problems however and just like everything, is not perfect. But I don't think C++ can become "as good as Rust" when it comes to correctness/soundness/safety and eventually tbh. also performance.

[intelfx]

Why?
Package managers are awesome. If something isn't supported by the standard library, how else am I going to get that functionality? Go on some random website and download a ZIP file that then gets outdated?

Package managers are awesome, but having 20 independent package managers stepping onto each other's toes is anything but awesome. It is a royal pain in the ass to develop or deploy a project that has multiple languages in its dependency graph.

This problem must be tackled from the other end, see Nix.

[bug77]

Hardly - there are vast areas of programming with billions of dollars of investment barely moving out moved to C++11. Obviously, advanced features such as modules, coroutines, concepts and pals do not bear much significance to those. It's not going to die anytime soon (as in decades).

That's not proof some projects don't care about these features. That's just proof that it's hard for C++ to demonstrate correctness.

Package managers are awesome, but having 20 independent package managers stepping onto each other's toes is anything but awesome. It is a royal pain in the ass to develop or deploy a project that has multiple languages in its dependency graph.

This problem must be tackled from the other end, see Nix.

Universal dependency managers have been with us since forever. Ivy, for example, is over 10 years old. Guess why they still haven't taken off?