{"action":"created","issue":{"url":"https://api.github.com/repos/scalaz/scalaz/issues/1519","repository_url":"https://api.github.com/repos/scalaz/scalaz","labels_url":"https://api.github.com/repos/scalaz/scalaz/issues/1519/labels{/name}","comments_url":"https://api.github.com/repos/scalaz/scalaz/issues/1519/comments","events_url":"https://api.github.com/repos/scalaz/scalaz/issues/1519/events","html_url":"https://github.com/scalaz/scalaz/pull/1519","id":274651607,"number":1519,"title":"Scalaz 8 IO pull request!","user":{"login":"jdegoes","id":156745,"avatar_url":"https://avatars1.githubusercontent.com/u/156745?v=4","gravatar_id":"","url":"https://api.github.com/users/jdegoes","html_url":"https://github.com/jdegoes","followers_url":"https://api.github.com/users/jdegoes/followers","following_url":"https://api.github.com/users/jdegoes/following{/other_user}","gists_url":"https://api.github.com/users/jdegoes/gists{/gist_id}","starred_url":"https://api.github.com/users/jdegoes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jdegoes/subscriptions","organizations_url":"https://api.github.com/users/jdegoes/orgs","repos_url":"https://api.github.com/users/jdegoes/repos","events_url":"https://api.github.com/users/jdegoes/events{/privacy}","received_events_url":"https://api.github.com/users/jdegoes/received_events","type":"User","site_admin":false},"labels":[{"id":385574322,"url":"https://api.github.com/repos/scalaz/scalaz/labels/scalaz8","name":"scalaz8","color":"fbca04","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":19,"created_at":"2017-11-16T20:23:25Z","updated_at":"2017-12-02T13:46:19Z","closed_at":null,"author_association":"OWNER","pull_request":{"url":"https://api.github.com/repos/scalaz/scalaz/pulls/1519","html_url":"https://github.com/scalaz/scalaz/pull/1519","diff_url":"https://github.com/scalaz/scalaz/pull/1519.diff","patch_url":"https://github.com/scalaz/scalaz/pull/1519.patch"},"body":"\r\nThis is a WIP pull request for the Scalaz 8 IO data type and JVM-based runtime system. This is intended to be a wholesale replacement for Scalaz 7 `IO` and `Task`.\r\n\r\nThis pull request includes the following components:\r\n\r\n * `scalaz.effect.IO` &mdash; The core `IO` data type, which models synchronous and asynchronous effects, with a concurrency model built on fibers and primitives and semantics similar to Haskell's `Async` package.\r\n * `scalaz.effect.RTS` &mdash; The runtime system for the JVM, which is capable of effectfully and efficiently interpreting an `IO` program.\r\n * `scalaz.effect.SafeApp` &mdash; The entry point for pure functional programs, which is integrated into the runtime system.\r\n * `scalaz.effect.IORef` &mdash; A mutable reference similar to Haskell's `IORef` data type.\r\n * `scalaz.effect.MVar` &mdash; A concurrent variable similar to Haskell's `MVar` data type.\r\n * Miscellaneous other utility data types, such as `BracketResult`, `AsyncReturn`, and so on.\r\n\r\nIn addition, a new `benchmarks` project has been added with competitive benchmarks (Scala `Future`, cats-effect `IO`, and Monix `Task`), which are quite useful for auditing and optimizing the performance of Scalaz 8 `IO`.\r\n\r\nThe following work remains outstanding:\r\n\r\n * **Type Class Hierarchy** &mdash; Some work has been done formalizing algebraic and operational laws in a type class hierarchy (`MonadFork`, `Catchable`, etc.), but there is more work to do in fleshing out the design.\r\n * **Unit Tests** &mdash; The JVM runtime system for `IO` has a growing test suite but many more tests are required, especially for concurrent primitives. Bugs are expected, but at this stage, most should be straightforward to fix. `MVar` has no test suite and should be considered a sketch.\r\n * **Performance** &mdash; Performance is very good in most cases, but now that the design is settled, optimization can yield additional improvements, especially in edge cases. Some code has not been optimized for several major iterations and several scalac compiler versions, so additional low-hanging fruit may exist.\r\n * **Concurrency** &mdash; The current cooperative yielding model is too primitive and thread pool perfunctory, with inadequate control for those needing more powerful knobs for thread shifting. Both of these will be greatly improved in a newer design.\r\n * **Javascript RTS** &mdash; There currently exists no Javascript runtime system, though almost identical semantics have already been implemented in PureScript so there is an existence proof.\r\n * **Benchmarks** &mdash; Additional benchmarks would be useful to cover mixed load and purely asynchronous load use cases, as well as benchmarks for `MVar` when the implementation has been tested and stabilized.\r\n * **Code Cleanup** &mdash; The runtime system implementation is intended to be low-level, and some duplication is necessary to minimize heap allocations. However, the code can benefit from better organization and some strategic simplifications.\r\n \r\nWhile there is more work that can and must be done, the code has reached a sufficient level of completeness and maturity that it can benefit from outside feedback and collaborators. So with the goal of encouraging this feedback and opening the door to third-party contributions, I am quite happy to present this WIP pull request for Scalaz 8 IO!\r\n\r\nThanks to all those whose feedback and work in other projects inspired and enabled my work here, including Vincent Marquez for the encouragement to work on this project, Alex Nedelscu for the inspiration to work on performance, Daniel Spiewak for his work on a type class hierarchy for effects, and many others for feedback around error handling.\r\n\r\nPlease dig in, break stuff, and provide whatever feedback or contributions you are inspired to provide!"},"comment":{"url":"https://api.github.com/repos/scalaz/scalaz/issues/comments/348693088","html_url":"https://github.com/scalaz/scalaz/pull/1519#issuecomment-348693088","issue_url":"https://api.github.com/repos/scalaz/scalaz/issues/1519","id":348693088,"user":{"login":"eleaar","id":423885,"avatar_url":"https://avatars2.githubusercontent.com/u/423885?v=4","gravatar_id":"","url":"https://api.github.com/users/eleaar","html_url":"https://github.com/eleaar","followers_url":"https://api.github.com/users/eleaar/followers","following_url":"https://api.github.com/users/eleaar/following{/other_user}","gists_url":"https://api.github.com/users/eleaar/gists{/gist_id}","starred_url":"https://api.github.com/users/eleaar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eleaar/subscriptions","organizations_url":"https://api.github.com/users/eleaar/orgs","repos_url":"https://api.github.com/users/eleaar/repos","events_url":"https://api.github.com/users/eleaar/events{/privacy}","received_events_url":"https://api.github.com/users/eleaar/received_events","type":"User","site_admin":false},"created_at":"2017-12-02T13:46:19Z","updated_at":"2017-12-02T13:46:19Z","author_association":"NONE","body":"@jdegoes @mielientiev The transformation from `IO` -> `Future` could be easily doable with just a few changes to the existing code, by separating the actual fiber runtime from the interpreter itself.\r\n\r\nI've spiked an example here: https://github.com/jdegoes/scalaz/pull/3. \r\nWhat do you think of it?"}}
{"actor":{"display_login":"eleaar"}}