this post was submitted on 26 Mar 2025
537 points (97.0% liked)

Programmer Humor

22131 readers
1619 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Opisek@lemmy.world 7 points 5 days ago (1 children)

I absolutely love how easy multi threading and communication between threads is made in Go. Easily one of the biggest selling points.

[–] firelizzard@programming.dev 1 points 3 days ago (1 children)

Key point: they're not threads, at least not in the traditional sense. That makes a huge difference under the hood.

[–] Opisek@lemmy.world 1 points 3 days ago* (last edited 3 days ago) (1 children)

Well, they're userspace threads. That's still concurrency just like kernel threads.

Also, it still uses kernel threads, just not for every single goroutine.

[–] firelizzard@programming.dev 1 points 2 days ago (1 children)

What I mean is, from the perspective of performance they are very different. In a language like C where (p)threads are kernel threads, creating a new thread is only marginally less expensive than creating a new process (in Linux, not sure about Windows). In comparison creating a new 'user thread' in Go is exceedingly cheap. Creating 10s of thousands of goroutines is feasible. Creating 10s of thousands of threads is a problem.

Also, it still uses kernel threads, just not for every single goroutine.

This touches on the other major difference. There is zero connection between the number of goroutines a program spawns and the number of kernel threads it spawns. A program using kernel threads is relying on the kernel's scheduler which adds a lot of complexity and non-determinism. But a Go program uses the same number of kernel threads (assuming the same hardware and you don't mess with GOMAXPROCS) regardless of the number of goroutines it uses, and the goroutines are cooperatively scheduled by the runtime instead of preemptively scheduled by the kernel.

[–] Opisek@lemmy.world 1 points 2 days ago* (last edited 2 days ago)

Great details! I know the difference personally, but this is a really nice explanation for other readers.

About the last point though: I'm not sure Go always uses the maximum amount of kernel threads it is allowed to use. I read it spawns one on blocking syscalls, but I can't confirm that. I could imagine it would make sense for it to spawn them lazily and then keep around to lessen the overhead of creating it in case it's needed later again, but that is speculation.

Edit: I dove a bit deeper. It seems that nowadays it spawns as many kernel threads as CPU cores available plus additional ones for blocking syscalls. https://go.dev/doc/go1.5 https://docs.google.com/document/u/0/d/1At2Ls5_fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/mobilebasic