[hecturchi]

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 ).

[jzoch]

Rust 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]

Maybe 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]

The 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]

I'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...

[lachlan-sneff]

Rust can easily do the same.