{"action":"closed","issue":{"url":"https://api.github.com/repos/alexcrichton/futures-rs/issues/24","repository_url":"https://api.github.com/repos/alexcrichton/futures-rs","labels_url":"https://api.github.com/repos/alexcrichton/futures-rs/issues/24/labels{/name}","comments_url":"https://api.github.com/repos/alexcrichton/futures-rs/issues/24/comments","events_url":"https://api.github.com/repos/alexcrichton/futures-rs/issues/24/events","html_url":"https://github.com/alexcrichton/futures-rs/issues/24","id":170152107,"number":24,"title":"Future ~ Result, Stream ~ Iterator","user":{"login":"killercup","id":20063,"avatar_url":"https://avatars.githubusercontent.com/u/20063?v=3","gravatar_id":"","url":"https://api.github.com/users/killercup","html_url":"https://github.com/killercup","followers_url":"https://api.github.com/users/killercup/followers","following_url":"https://api.github.com/users/killercup/following{/other_user}","gists_url":"https://api.github.com/users/killercup/gists{/gist_id}","starred_url":"https://api.github.com/users/killercup/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/killercup/subscriptions","organizations_url":"https://api.github.com/users/killercup/orgs","repos_url":"https://api.github.com/users/killercup/repos","events_url":"https://api.github.com/users/killercup/events{/privacy}","received_events_url":"https://api.github.com/users/killercup/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-08-09T12:19:59Z","updated_at":"2016-08-09T17:52:02Z","closed_at":"2016-08-09T17:52:02Z","body":"@alexcrichton, in the tutorial (and other places) you liken `Future` to `Iterator`, and `Stream` to… errr, nothing, IIRC.\r\n\r\nBut isn't the correlation more like this?\r\n\r\n| # items | Sync | Async | Common operations |\r\n| ----- | ----- | ------ | ----- |\r\n| 1 | `Result<T, E>` | `Future<T, E>` | `map`, `and_then`, `joinN` (a.k.a. `zip`!) |\r\n| ∞ | `Iterator<_>` | `Stream<_>`| `map`, `fold`, `collect`, `flatten` |\r\n\r\nMany operators on `Option`/`Result`/`Iterator` has the same/similar names and semantics (… monads…), so the key differentiator is the number of items they can yield. (With respect to `Stream`'s error handling, the sync side should be `Iterator<Item=Result<T,E>`.)\r\n\r\nOr am I missing some key insight of the implementation? I started reading the tutorial on this earlier, and my background is JS async primitives. (That Streams are actually Futures yielding `(val, next_future)` is a pretty nice property, btw.)"}}
{"actor":{"display_login":"alexcrichton"}}