{"id":18014856,"url":"https://github.com/zevv/nim-async-issue","last_synced_at":"2026-02-08T19:02:45.642Z","repository":{"id":150599182,"uuid":"199164865","full_name":"zevv/nim-async-issue","owner":"zevv","description":null,"archived":false,"fork":false,"pushed_at":"2019-07-27T21:44:12.000Z","size":8,"stargazers_count":1,"open_issues_count":3,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-12-13T13:17:18.642Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/zevv.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-07-27T12:55:29.000Z","updated_at":"2019-07-28T07:53:53.000Z","dependencies_parsed_at":"2023-06-11T17:15:06.918Z","dependency_job_id":null,"html_url":"https://github.com/zevv/nim-async-issue","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/zevv/nim-async-issue","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zevv%2Fnim-async-issue","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zevv%2Fnim-async-issue/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zevv%2Fnim-async-issue/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zevv%2Fnim-async-issue/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/zevv","download_url":"https://codeload.github.com/zevv/nim-async-issue/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zevv%2Fnim-async-issue/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29240136,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-08T18:06:38.086Z","status":"ssl_error","status_checked_at":"2026-02-08T18:06:09.124Z","response_time":57,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-30T04:11:24.416Z","updated_at":"2026-02-08T19:02:45.616Z","avatar_url":"https://github.com/zevv.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# TL;DR\n\nThere are two incompatible async I/O libraries available for Nim, which is not\na good thing given the fundamental layer at which these libraries operate. The\nrisk is that this might split the library ecosystem. I hope to find a\nresolution for this situation that makes everybody happy and foster the Nim ecosystem.\n\n# Background\n\nOver the last few weeks/months I have seen a number of discussions[3] on the Nim\nforum and the #nim IRC channel about the state of the Nim async library. After\nspeaking with some (but not all!) of the people involved I figured it is time\nto make this into an official discussion to see how this can be resolved and we\ncan move forward.\n\nHere is the back story:\n\n- The Nim stdlib comes with a library for doing async (network) I/O, consisting\n  of asyncmacro, asyncdispatch, asyncnet and ioselectors. This has been part of\n  the standard library for a few years, and is the base layer on which things\n  like asyncHttp are built. A well-known application using stdlib async is the\n  Nim forum itself.\n\n- Implementing async I/O is not trivial, and the Nim libraries has had some\n  bugs, missing features or other issues. Some were fixed and addressed in the\n  past, but some are still open [4][5]. Also, some issues are more serious then\n  others: some are considered blockers[2][6] for a 1.0 Nim release.\n\n- A bit over a year ago a third-party implementation of async I/O called\n  `Chronos`[1] was created by people who were not content with the quality\n  and stability of the async layer at that time and found that these issues\n  were not timely addressed by the Nim maintainers. [7][8][10][11][12]\n\n- Chronos was partially forked from the Nim async library, while other parts\n  were rewritten from scratch. Chronos's API is not compatible with Nims async\n  lib, as API changes were deemed necessery to fix underlying issues.\n  \n- Chronos has seen steady development over the last year, diverging more and\n  more from Nim async, but also fixing some of the issues that were in the Nim\n  standard library. Chronos is developed at Status, the main Nim sponsor, as a\n  core component of Nimbus, a client for the Ethereum blockchain and\n  nim-libp2p, a standard for P2P protocol.\n\n# The problem\n\nGiven the above history, the Nim community has now two different but\nincompatible Async implementations. Async I/O is an important piece of core\ninfrastructure which provides the foundation for a lot of other protocol\nimplementations. Having two incompatible and mutually exclusive async\nframeworks is probably not a good thing for the community - should I implement\nmy new protocol on top of the one or the other? Or both? What if I choose the\none but want to use a 3d party lib that depends on the other?\n\nRecently things have slightly \"escalated\" in various threads on the Nim forum -\nusers asking questions or noting issues with Nim async are pointed to Chronos\nas a solution to their problem. While this answers is perfectly legit and might\nhelp the user with their problem, this might give rise to confusion among new\nusers, and does not help the current stdlib to evolve and get better.\n\n# Where to go from here?\n\nI think we should get this resolved, and I hope to start a discussion here so\nwe can figure out the right thing to do. Some questions?\n\n- Do we accept the status quo? There are two available implementations, and\n  users should be free to choose?\n- Should the Nim stdlib drop the current implementation in favour of Chronos?\n  If so, when? What about Nim 1.0?\n- Should we put work into getting the two implementations to cooperate?\n- Can we add a Chronos-compatibility layer on top of the Nim libs, or add a\n  Nim-compatibility layer on top of Chronos?\n\nHere are the important points that I think should be addressed in this\ndiscussion:\n\n- API stability: The Nim Async layer tries to provide a stable API on which\n  other protocols have been implemented. Chronos has had good reasons to make\n  changes, but this broke compatibility with existing and future Nim-async\n  libraries.\n\n- Code quality: At this time Chronos is seeing a lot of active development\n  backed by a commercial party. This simply allows Chronos to fix more of the\n  technical debt and add more features. A lot of Nim stdlib development is done\n  by volunteers which have to do this in their free time for no pay.\n\n- Nim 1.0 is coming up. We probably want to resolve this and have a good story\n  before the release.\n\n# Rules for the discussion\n\n- Given the nature of past discussions about this subject, I would like to ask\n  all parties involved to refrain from having any of these elsewhere while this\n  RFC is on the table. I think no one benefits from a forum full of threads\n  where the good and the bad of implementations are compared and mud gets\n  thrown around.\n\n- I try to see myself as neutral party in this discussion, and I plan to\n  moderate this discussion and remove or move off-topic posts to keep the\n  discussion focused on the above questions.\n\n# References\n\nChronos repo:\n\n- [1] https://github.com/status-im/nim-chronos\n\nRecent forum discussion:\n\n- [3] https://forum.nim-lang.org/t/5048\n\nRelevant open nim stdlib issues:\n\n- [2] https://github.com/nim-lang/Nim/issues/8080\n- [4] https://github.com/nim-lang/Nim/issues/3590\n- [5] https://github.com/nim-lang/Nim/issues/4123\n- [6] https://github.com/nim-lang/Nim/issues/7126\n- [9] https://github.com/nim-lang/Nim/issues/7193\n\nClosed Nim stdlib issues (inc days-to-fix)\n\n- [7] https://github.com/nim-lang/Nim/issues/7758 (113)\n- [8] https://github.com/nim-lang/Nim/issues/7197 (273)\n- [10] https://github.com/nim-lang/Nim/issues/7192 (281)\n- [11] https://github.com/nim-lang/Nim/issues/6846 (266)\n- [12] https://github.com/nim-lang/Nim/issues/6929 (252)\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzevv%2Fnim-async-issue","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fzevv%2Fnim-async-issue","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzevv%2Fnim-async-issue/lists"}