{"action":"created","issue":{"url":"https://api.github.com/repos/daokoder/dao/issues/393","labels_url":"https://api.github.com/repos/daokoder/dao/issues/393/labels{/name}","comments_url":"https://api.github.com/repos/daokoder/dao/issues/393/comments","events_url":"https://api.github.com/repos/daokoder/dao/issues/393/events","html_url":"https://github.com/daokoder/dao/issues/393","id":67204190,"number":393,"title":"Revisiting async classes","user":{"login":"Night-walker","id":5074460,"avatar_url":"https://avatars.githubusercontent.com/u/5074460?v=3","gravatar_id":"","url":"https://api.github.com/users/Night-walker","html_url":"https://github.com/Night-walker","followers_url":"https://api.github.com/users/Night-walker/followers","following_url":"https://api.github.com/users/Night-walker/following{/other_user}","gists_url":"https://api.github.com/users/Night-walker/gists{/gist_id}","starred_url":"https://api.github.com/users/Night-walker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Night-walker/subscriptions","organizations_url":"https://api.github.com/users/Night-walker/orgs","repos_url":"https://api.github.com/users/Night-walker/repos","events_url":"https://api.github.com/users/Night-walker/events{/privacy}","received_events_url":"https://api.github.com/users/Night-walker/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-04-08T19:43:55Z","updated_at":"2015-04-10T06:24:41Z","closed_at":null,"body":"It's not the first time I have doubts if asynchronous classes are necessary for the language in their current form. Well, that's another episode of this story.\r\n\r\nAsync classes seem like a nice idea, but for a *very* specific use case. The one ~~we haven't found yet~~ which requires high-level service-like threading model while staying simple enough for async classes to be applicable in the first place. \r\n\r\nI mean, for trivial concurrency we don't need anything but magical `!!` -- excitement operator :) -- and channels with futures. For complex, large-scale tasks the ability to wrap inter-thread communications in method calls (that's what async classes are essentially about) will probably not be the most important thing to care about. Usually some broader, more comprehensive metaphor is applied in such cases, namely the actor model.\r\n\r\nBy getting rid of async classes we not just make the language simpler, -- arguably the largest single place ~~haunted by demons~~ of possible inter-feature conflicts disappears. A lot of potential issues regarding integration of async classes into the language evaporate immediately. I think it would make things simpler.\r\n\r\nIt may still be reasonable to reserve way to imitate async class behavior -- it could be provided by dedicated module in the standard library. Not the exact semantics -- that's hardly doable without direct syntax support -- but perhaps some building blocks to construct similar communication model.\r\n\r\nOverall, I believe that the basis, backbone of Dao should ideally consist of simple elements backed by universal principles. Small and flexible things are easier to combine and intermix, their potential is often greater, whereas complex and specialized abstractions always require special treatment and rules. Ditching async class will leave us with much lesser amount of design problems to worry about."},"comment":{"url":"https://api.github.com/repos/daokoder/dao/issues/comments/91448152","html_url":"https://github.com/daokoder/dao/issues/393#issuecomment-91448152","issue_url":"https://api.github.com/repos/daokoder/dao/issues/393","id":91448152,"user":{"login":"Night-walker","id":5074460,"avatar_url":"https://avatars.githubusercontent.com/u/5074460?v=3","gravatar_id":"","url":"https://api.github.com/users/Night-walker","html_url":"https://github.com/Night-walker","followers_url":"https://api.github.com/users/Night-walker/followers","following_url":"https://api.github.com/users/Night-walker/following{/other_user}","gists_url":"https://api.github.com/users/Night-walker/gists{/gist_id}","starred_url":"https://api.github.com/users/Night-walker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Night-walker/subscriptions","organizations_url":"https://api.github.com/users/Night-walker/orgs","repos_url":"https://api.github.com/users/Night-walker/repos","events_url":"https://api.github.com/users/Night-walker/events{/privacy}","received_events_url":"https://api.github.com/users/Night-walker/received_events","type":"User","site_admin":false},"created_at":"2015-04-10T06:24:41Z","updated_at":"2015-04-10T06:24:41Z","body":"> They are simple to use, however.\r\n> This might become the reason overweighting their limitations and justifying their existence in Dao.\r\n\r\nIt's not enough if async classes are falling outside of major use cases. \r\n\r\n> Not at the moment, that may require some considerations.\r\n> Me neither, but I'll think about it a little (I'm afraid, I'll end up with a copy of some existing actor model implementation).\r\n\r\nAsync classes have little to do with the actor model. They usually cannot be used where actors are typically employed, hence my doubts about their utility.\r\n\r\nBasically, the largest thing necessary to emulate async classes is the ability to create future value without creating new task. Supporting that would open way to achieve the same kind of communication without touching the syntax."}}