2 HN users recommended this talk2 months2020–2026score 2
Years with an HN recommendation, 2007–2026
Recommended as a good watch on how Go's M:N:P scheduler works and why it was designed that way compared with alternative schemes.
Go runtime contributor Dmitry Vyukov looks inside the Go scheduler, explaining how goroutines and channels are implemented. He covers the main scheduler components and overall operation, then goes into details such as preemption and stacks.
“This one notably also explains the design considerations for golangs M:N:P in comparison to other schemes” (HN, 2026)
I guess that's because they are "intros," and often multi-core event loops are implemented by the language runtime or some threadpool library. This is a good watch: Dmitry Vyukov — Go scheduler: Implementing language with lightweight concurrency (Oct 14, 2019) [this video]
[this video] - Dmitry Vyukov — Go scheduler: Implementing language with lightweight concurrency This one notably also explains the design considerations for golangs M:N:P in comparison to other schemes and which specific challenges it tries to address.
Explains design considerations behind Go's M:N:P scheduler versus other schemes
Go depends on the fact that it can track all pointers, and when it needs to resize stacks, it can update them. Previous versions of Go used segmented stacks, which are theoretically possible, if Zig really wanted (would need compiler support), but they have nasty performance side-effects, see [this video]
Explains performance problems of segmented stacks in Go
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
3 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes