News for hackers. Stuff that matters.
[dead]
Re:How Rust optimizes async/await by pcwalton on Monday August 19, 2019 @02:48PM (#20740559)
If you think that Rust doesn't care about addressing the needs of C++ users, I'm not sure what to tell you.

It's not like C++ only focuses on features with zero overhead. The zero-overhead principle means that you don't pay for what you don't use. It doesn't mean that compiler developers are forbidden from working on any language or library feature that consumes more than zero cycles at runtime.

[dead]
Re:How Rust optimizes async/await by kbenson on Monday August 19, 2019 @04:30PM (#20741500)
I think the issue is that the zero-cost abstraction terminology is used in two ways often. First, to mean a feature you can use and costs nothing because the compiler will change it into a more common form for you (such as functional programming approaches where it will take multiple filters and map passes and turn it into a single loop), and second, to mean that features added that do add overhead, only do so when you use them (as in, there's no runtime to manage M:N threading unless you include a crate that does so, because developers not using that feature shouldn't have to pay for it).

I think the terminology here is looser than it should be, and these are not really the same thing, even though I've seen zero-cost abstractions used to describe them both. It causes confusion sometimes, as I believe it is doing here.

Re:How Rust optimizes async/await by quietbritishjim on Tuesday August 20, 2019 @09:37AM (#20746849)
Sure, and there are a few hooks for one in the C++ standard library e.g. std::declare_reachable [1], although it doesn't include an actual implementation. Only mark and sweep is feasible, not mark and compact, for obvious reasons [2]. Here's a mention of garbage collection Stroustrop's old C++11 FAQ [3]

[1] https://en.cppreference.com/w/cpp/memory/gc/declare_reachabl...

[2] https://herbsutter.com/2011/10/25/garbage-collection-synopsi...

[3] https://web.archive.org/web/20120228143039/http://www2.resea...

Re:How Rust optimizes async/await by pcwalton on Monday August 19, 2019 @03:06PM (#20740757)
Sure. It's called Rc and Arc.
Re:How Rust optimizes async/await by jnordwick on Tuesday August 20, 2019 @02:17AM (#20744256)
Don't be intentionally obtuse. You know I mean something more like mark and sweep
Re:How Rust optimizes async/await by hexane360 on Monday August 19, 2019 @09:40PM (#20743177)
Re:How Rust optimizes async/await by pcwalton on Monday August 19, 2019 @09:56PM (#20743250)
Reference counting is a form of garbage collection, despite the fact that it does not detect cycles without extra work. This has been the correct terminology in the memory management literature for decades.
Re:How Rust optimizes async/await by nemothekid on Monday August 19, 2019 @09:27PM (#20743134)
Is shared_ptr a zero cost abstraction?
Re:How Rust optimizes async/await by kam on Monday August 19, 2019 @10:13PM (#20743320)
Mostly, with the caveat that in single threaded usage, you're paying for the unnecessary overhead of atomic ops on the reference count.

Rust has `Rc`, which is not atomic but `!Send` so the type system ensures that it stays within a thread, as well as the atomic `Arc`.