4 ms·
My impression of the article is just that the author is a fan of green threads (goroutines). Green threads don’t really make sense without an integration into s
by travisd 5y ago
My impression of the article is just that the author is a fan of green threads (goroutines). Green threads don’t really make sense without an integration into some kind of IO runtime, so calling out how Go does do this seems moot. Other languages with green threads also with this way (Julia comes to mind).
- karmakaze 5y agoThe article is not very well informed. It doesn't even make a distinction between os threads and green threads. > To get this performance out of Java you would need to add threadpools, futures or some other async library. What Java needs to be as efficient is the work of Project Loom: Fibers and Continuations. Go also has value types (e.g. arrays and nested structs with inline memory layout) that's the work of Java's Project Valhalla.
- zik 5y agogoroutines aren't really green threads, they're more lightweight than conventional green thread implementations due to having a segmented stack. Millions of goroutines can run comfortably on a standard machine. This isn't possible with any green thread implementation I've seen. https://blog.cloudflare.com/how-stacks-are-handled-in-go/ https://blog.cloudflare.com/how-stacks-are-handled-in-go/
- kortilla 5y agoThey are cheaper but conceptually aren’t any different.
- lucian1900 5y agoYou can run that many Erlang processes or more. Millions is typical of green thread implementations.
- nasretdinov 5y agoBy the way, while Go did initially have segmented stacjs, they've long abandoned it in favour of a contiguous one.