--- title: Rust concurrency vs Go concurrency: stackless vs... description: A comparison of how Rust and Go handle concurrency at a fundamental level: Go uses stackful coroutines (goroutines/green threads) scheduled M:N onto kernel... canonical: https://daily.dev/posts/rust-concurrency-vs-go-concurrency-stackless-vs-stackfull-coroutines-7wpfxbf6k twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Rust concurrency vs Go concurrency: stackless vs stackfull coroutines | daily.dev og:description: A comparison of how Rust and Go handle concurrency at a fundamental level: Go uses stackful coroutines (goroutines/green threads) scheduled M:N onto kernel... og:url: https://daily.dev/posts/rust-concurrency-vs-go-concurrency-stackless-vs-stackfull-coroutines-7wpfxbf6k og:image: https://api.daily.dev/og/posts/7WPFXBf6K.png og:image:alt: Rust concurrency vs Go concurrency: stackless vs stackfull coroutines og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Rust concurrency vs Go concurrency: stackless vs stackfull coroutines **[Sylvain Kerkour](https://daily.dev/sources/kerkour)** · 6 min read · 5 upvotes · 0 comments ## Summary A comparison of how Rust and Go handle concurrency at a fundamental level: Go uses stackful coroutines (goroutines/green threads) scheduled M:N onto kernel threads, while Rust uses stackless coroutines compiled into state machines via async/await. The piece explains tasks and runtimes, then contrasts trade-offs: Go's goroutines each need a minimum stack (2 KiB as of Go 1.22, so 10,000 goroutines use at least 20 MiB) and complicate C FFI interop (CGO), while Rust's approach avoids per-task stacks but suffers from function-coloring problems, ecosystem fragmentation across runtimes like tokio, and the need to avoid blocking the event loop. It closes arguing Rust's fragmented async ecosystem is a real adoption obstacle, with links to related deep-dives and the author's books. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the minimum memory used by a single goroutine in Go 1.22? Each goroutine uses a minimum of 2 KiB of stack memory as of Go 1.22. This means running 10,000 concurrent goroutines requires at least 20 MiB of memory just for stacks, since Go's stackful coroutine model gives every task its own growable stack. _Developers sizing concurrent Go workloads can track runtime memory behavior details like this on daily.dev._ ### Why is Rust's async ecosystem considered fragmented compared to Go's concurrency model? Rust's async runtimes, such as tokio, are not interoperable with each other, so code written for one runtime is hard to port to another. Combined with function coloring, where sync code cannot call async code directly, and a standard library that lacks async equivalents of common sync functions, this fragments the ecosystem and forces each project to reinvent solutions. _Anyone weighing tokio against other Rust runtimes can follow ecosystem trade-off discussions like this on daily.dev._ ### Why does Go's goroutine model make C FFI calls through CGO slower than native Go code? Because Go's stackful coroutines require the runtime to have complete control over stack layout, the runtime must do extra preparation work on the stack before calling into C code via CGO. In practice this overhead measures around 30 to 75 nanoseconds per call, which is fast in absolute terms but still a real, structural cost of the stackful concurrency model. _Developers debugging CGO performance can compare runtime trade-offs like this one on daily.dev._ --- Tags: [#golang](https://daily.dev/tags/golang), [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/rust-concurrency-vs-go-concurrency-stackless-vs-stackfull-coroutines-7wpfxbf6k) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Rust concurrency vs Go concurrency: stackless vs stackfull coroutines","url":"https://daily.dev/posts/rust-concurrency-vs-go-concurrency-stackless-vs-stackfull-coroutines-7wpfxbf6k","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/rust-concurrency-vs-go-concurrency-stackless-vs-stackfull-coroutines-7wpfxbf6k"},"datePublished":"2026-09-02T16:54:24.595Z","dateModified":"2026-09-02T18:33:24.723Z","description":"A comparison of how Rust and Go handle concurrency at a fundamental level: Go uses stackful coroutines (goroutines/green threads) scheduled M:N onto kernel...","image":"https://media.daily.dev/image/upload/s--P4t4XyoV--/f_auto/v1722860399/public/Placeholder%2001","thumbnailUrl":"https://media.daily.dev/image/upload/s--P4t4XyoV--/f_auto/v1722860399/public/Placeholder%2001","isAccessibleForFree":true,"articleSection":"Sylvain Kerkour","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Sylvain Kerkour","logo":"https://media.daily.dev/image/upload/s--3ngWt4Yp--/f_auto,q_auto/v1786438308/logos/kerkour?_a=BAMAMicg0","url":"https://daily.dev/sources/kerkour"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/rust-concurrency-vs-go-concurrency-stackless-vs-stackfull-coroutines-7wpfxbf6k","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":5},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"golang,rust","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Sylvain Kerkour","item":"https://daily.dev/sources/kerkour"},{"@type":"ListItem","position":3,"name":"Rust concurrency vs Go concurrency: stackless vs stackfull coroutines"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/rust-concurrency-vs-go-concurrency-stackless-vs-stackfull-coroutines-7wpfxbf6k#faq","mainEntity":[{"@type":"Question","name":"What is the minimum memory used by a single goroutine in Go 1.22?","acceptedAnswer":{"@type":"Answer","text":"Each goroutine uses a minimum of 2 KiB of stack memory as of Go 1.22. This means running 10,000 concurrent goroutines requires at least 20 MiB of memory just for stacks, since Go's stackful coroutine model gives every task its own growable stack. Developers sizing concurrent Go workloads can track runtime memory behavior details like this on daily.dev."}},{"@type":"Question","name":"Why is Rust's async ecosystem considered fragmented compared to Go's concurrency model?","acceptedAnswer":{"@type":"Answer","text":"Rust's async runtimes, such as tokio, are not interoperable with each other, so code written for one runtime is hard to port to another. Combined with function coloring, where sync code cannot call async code directly, and a standard library that lacks async equivalents of common sync functions, this fragments the ecosystem and forces each project to reinvent solutions. Anyone weighing tokio against other Rust runtimes can follow ecosystem trade-off discussions like this on daily.dev."}},{"@type":"Question","name":"Why does Go's goroutine model make C FFI calls through CGO slower than native Go code?","acceptedAnswer":{"@type":"Answer","text":"Because Go's stackful coroutines require the runtime to have complete control over stack layout, the runtime must do extra preparation work on the stack before calling into C code via CGO. In practice this overhead measures around 30 to 75 nanoseconds per call, which is fast in absolute terms but still a real, structural cost of the stackful concurrency model. Developers debugging CGO performance can compare runtime trade-offs like this one on daily.dev."}}]} ```