Viewing profile — tmandry

My hope is that you can use Send variants generated with the macro to reduce the typing, in cases where you need that. In the future with return type bounds, middleware would just …

I don't have numbers handy, but I can say with confidence that the answer to both questions is "yes". It depends on the use case. Boxing is a useful tool and in many cases the over…

Study design: Tracks 200 people over one year and measures a suite of biomarkers at the beginning, 6 months, and 12 months. Participants are randomly assigned to one of four dosage…

> Otherwise we are always dependent on the good will of the companies without democratic control. Yes, but that’s already true without this action, which doesn’t make them any more…

Most libraries don’t target nightly anymore. It certainly used to be the case that nightly had all the cool features everyone wanted, but almost all features that popular crates de…

You seem to be hitting the nail on the head with regard to seamless UX. I’d gladly pay to support something like this, but the lock-in / “what happens if you go away” problem is re…

“mild” symptoms has been used to mean flu-like, i.e., not something I would call mild and certainly not the same as asympotomatic, but not requiring hospitalization.

I’m not sure I would call this a memory model per se, but here’s how async tasks are laid out in memory. http://tmandry.gitlab.io/blog/posts/optimizing-await-1/

Only models sold after a certain date support this, and you have to go through a menu sequence to enable HDMI 2. It’s documented on their website.

Just to clarify for those following along, Rust async code does not use green threads and doesn't require a stack per task.

I didn’t know about this.. I’d love to read that book :)

The concept of a pseudo-thread you're referring to is a task. A task contains a whole tree of futures awaiting other futures. So no manual propagation is necessary. Of course, it's…

Futures were developed outside Rust core, in a third-party library, before being brought into the language. Working with them in combinator form definitely was less ergonomic, but …

Disclaimer: I'm not an expert on the proposal, but have looked at it some, and can offer my impressions here. (Sorry, this got a bit long!) The C++ proposal definitely attacks the …

It's the same underlying mechanism for generators as for futures: they are stackless coroutines. All the space they need for local variables is allocated ahead of time. In my exper…

I'd agree with this, and emphasize the point that this stuff is really tricky to get right without GC. Fighting the borrow checker is somewhat expected when you're dealing with thi…

Generators do nothing unless you call their resume() method. resume moves the generator from the last state it was in to the next yield (or return). Internally, when the code hits …

This is a great quote, and one that I missed while first writing the post! I've added it now.

Most languages allocate every future (and sub-future, and sub-sub-future) separately on the heap. This leads to some overhead, allocating and deallocating space to store our task s…

Not necessarily. They're an implementation detail of the compiler, and aren't fully baked yet to boot. But there's plenty of reason to want generators, including the fact that they…

That's what I get for publishing late at night. Fixed, thanks!