Mention golang go keyword as alternative to async let

[clarfonthey]

Finally got around to reading #54 and I think that golang's go keyword should be mentioned as a direct alternative to async let from Swift. They perform similar operations, and the only difference is that golang doesn't actually allow capturing the return value from the operation, which could easily be rectified by making the expression return a future.

Essentially, I'm quite averse to the async let syntax since it seems to disrupt the purity of let as an operation: let is just assigning something, but async let is spawning a task and defining a handle to it, which feels a bit too overloaded. A very valid alternative would be to simply spawn a task and assign that to the let, i.e.:

let task = defer!(my_expression);

And if we were to implement async drop, then:

let _ = defer!(my_expression);

would be enough to simply defer the task until the end of the block.

[clarfonthey]

Hey y'all, simply reacting with a thumbs down to a suggestion and not providing any reasons why is kind of toxic, and it's worth mentioning that I'm bringing this up not because I think that it's the best design, but because we should explore the full design space.

From that perspective, explaining why you think that either:

1. This design is so bad we shouldn't mention it, or:
2. This design isn't actually related to what's being mentioned

Would be pretty helpful.

[yoshuawuyts]

@clarfonthey I'm sorry about my slow response - I believe I was on sick leave when you opened it, and I didn't get around to replying. With regards to the downvotes: I can see that being frustrating to be on the receiving end of, and I'm sorry about that.

To be honest, I'm not entirely clear what the right direction here would be? It's clear you disagree with the design. And in turn, I don't necessarily agree with the points you disagree on - so that ends up being a little confusing. I don't know how we could constructively include that in what is intended to be a brief explainer of a design worth exploring.

I do think feedback is important though, and I welcome the idea of exploring the downsides of this. If I can suggest an alternative: please write a blog post explaining your critique in more depth, include your alternative design, and then file a PR to link to that from the original post. That way both directions are documented on their own, but we make sure it's included. Would that work for you?

[clarfonthey]

Oh, I absolutely think it's fine to not provide feedback. I just personally have a general rule that I don't thumbs-down something unless I have the time to provide feedback, or someone has already provided the feedback I was going to give. I think that it's valuable to see the support for something and negative support is part of that, just, effectively amounting to five people saying "I don't like this" without anyone explaining why is just really toxic and unhelpful. It feels more like dogpiling than contributing in any valuable way.

In terms of what I'm describing: effectively, the issue is one of spawning background tasks in async context, and async let x = task() is one way of accomplishing this. However, another way is by having something similar to golang's defer task() keyword, and in Rust it would presumably be accomplished as something like let x = defer!(task());.

I'm personally against async let because it turns let, a normally immutable and functional construct, into a stateful construct. It's functionally equivalent to spawning a background task, which is mixing up concerns for me.

I'd be more than happy to write this up in a PR adding it alongside the existing async let suggestions, just, wanted to comment on the downvotes and explain why I thought they were unhelpful.

[yoshuawuyts]

Oh, I absolutely think it's fine to not provide feedback. I just personally have a general rule that I don't thumbs-down something unless I have the time to provide feedback, or someone has already provided the feedback I was going to give. I think that it's valuable to see the support for something and negative support is part of that, just, effectively amounting to five people saying "I don't like this" without anyone explaining why is just really toxic and unhelpful. It feels more like dogpiling than contributing in any valuable way.

Sorry, I don't think I said anything about it being okay not to provide feedback? To be clear, I'm in agreement that just emoji responses without any further clarification is often not very helpful. I've been on the receiving side of that, and yeah it's usually not great. You have my sincere sympathies.

In terms of what I'm describing: effectively, the issue is one of spawning background tasks in async context, and async let x = task() is one way of accomplishing this. However, another way is by having something similar to golang's defer task() keyword, and in Rust it would presumably be accomplished as something like let x = defer!(task());.

So to be clear: what was described in the design is not about spawning tasks in a strict sense. There is no executor, and no Task type involved. It also is not multi-threaded, and it does not allocate either. What it does do, though, is concurrent scheduling of futures via join hierarchies.

I'm so-so on the idea of including the alternative you're describing inline in the document. It's intentionally an incomplete design, meant to be used as a starting point for further exploration only. If it was a fully realized RFC, that would be different. Instead what I'm suggesting as an alternative here is: author a blog post (this can even be in gist form if you prefer), and we can link to it from the original document. That way your critique is not lost; but the document can stay relatively brief. Would that work for you?

[clarfonthey]

Sorry, I don't think I said anything about it being okay not to provide feedback? To be clear, I'm in agreement that just emoji responses without any further clarification is often not very helpful. I've been on the receiving side of that, and yeah it's usually not great. You have my sincere sympathies.

Sorry, I was mostly agreeing with you and just attempting to re-explain my points. All is good!

In terms of writing a blog post or something similar, I can try and look at that. I'll have to go back and see what the async let really means, since that still doesn't make a whole lot of sense to me.