4 ms·
FWIW, C++ has actually had stable async/await (I have been shipping a production product compiled to numerous platforms now for a year built with C++ coroutines
by saurik 6y ago
FWIW, C++ has actually had stable async/await (I have been shipping a production product compiled to numerous platforms now for a year built with C++ coroutines) since before Rust finished theirs (and from what I so far know about Rust's, I like C++'s better, though I admit I don't know enough enough about what Rust did). C++ also frankly has a much better cross-platform build system story, with more extensible and hookable builds (the ability to do header injection on library dependencies with #include_next is epic)... I have so many bugs filed against cargo and rustc with respect to even basic cross-compile scenarios it isn't funny anymore :/. (I mean, cargo doesn't even get reproducible builds for cross-compiled binaries correct, though at least I was able to figure out a super awkward workaround for that where I give it a "rustc wrapper" and then run a filter on the command line arguments to strip the host-specific cargo metadata.) Some of us also think Rust made the wrong call on not supporting exceptions (if you want to use "monadic error handling" but you don't actually support defining monads, something seriously broken happened). C++ also has faster serial build times than Rust and fundamentally better support for parallel and incremental compilation than Rust (due to its support for prototypes and translation units; I ship my builds off to AWS lambda and expect to get linear speedup on -j1000 now that Amazon supports EFS mounts). <- So like, while I might agree that Rust's build system is "simple and clean", the reality is that computers aren't and so it is a fundamental mistake to make such a rigid build system :/. Rust is also still lacking in some key type system features, such as being able to template over values (which lets you create compile-time safe buffer types), which is a frustrating tradeoff against Rust's feature of lifetimes (which is absolutely a good thing, but isn't actually a source of issues in my code vs. buffer handling: what I really want is even dependent types... if Rust had at least gone for full linear types it would sell me much more quickly, as dealing with those situations is currently miserable in both languages and I know I could use such a facility to prevent the vast majority of the issues I actually run into in my code with respect to asynchronous cross-computer behavior). C++'s obviously-trivial compatibility with the massive ecosystem of C/C++ libraries is also useful. And like, while I totally appreciate the reasons object oriented programming can suck, for GUI programming it is still an incredibly common paradigm that C++ supports but is directly supported by neither Rust nor Go (which I haven't complained about at all in this comment, but mostly because I consider it a competitor to Python, not C++).
- pjmlp 6y agoFor example, one can code with async/await in UWP via C++/WinRT today, without having to think which runtime to use, or possible incompatibilities across async runtimes.
- snuxoll 6y agoThat’s because WinRT already provides an async executor based on the Windows thread pool for you, C++ coroutines specify the plumbing for writing coroutines but nothing more, just like Rust - Microsoft just spent the time working up the WinRT async interfaces to coroutines.
- pjmlp 6y agoISO C++20 defines them in a way that the current incompatibilities in the Rust world aren't happening as such and any C++ library using concurrency features is expected to just work across compilers. ISO C++ also does not define how std::thread should be mapped into the host platform.