3 ms·
Go can handle 100k goroutines (green threads) without a sweat. This is useful for p2p systems in which you are connected to thousands of peers multiplexing sev
by hecturchi 6y ago
Go can handle 100k goroutines (green threads) without a sweat.
This is useful for p2p systems in which you are connected to thousands of peers multiplexing several p2p protocols with each concurrently. You want to be able to switch threads as fast as possible.
The concurrency model is a bit easier to reason about too.
It would be good to see how Rust and others do. Other languages excel at other things (i.e. embedded devices ).
- lachlan-sneff 6y agoRust can easily do the same.
- jzoch 6y agoRust can handle the same thing though the typical model now is using async-await and scheduling tasks on a threadpool. While I won't say its conceptually as simple as go can be, Rust also has channels, mutexes, and other concurrency primitives that allow you to create a similar story. It will also end up being more performant and less work to make correct (typically) due to its small runtime and extensive compile-time checking.
- hecturchi 6y agoMaybe if IPFS had started today they would have picked Rust. Honestly I'm not sure why Go was picked specificall, but if you put things in the context of 5 years ago it doesn't seem a crazy choice.
- SparkyMcUnicorn 6y agoThe Discord team wrote an article (or a few), and I think you'd find them very interesting.Specifically about their Go implementation, porting to Rust, and then the decision to use Rust wherever it makes sense as a result. They're very sensible about it, and advocate using the right tool for the job.
- m-p-3 6y agoI'm not sure if that applies here, but Discord switched a portion of their backend from Go to Rust because of some performance issues. https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...