Why Turborepo is migrating from Go to Rust

> While this sounds convenient, this abstraction does not work across platforms; Windows actually doesn't have the precise concept of file permissions. Go ends up allowing us to set a file permission code on Windows, even when doing so will have no effect. ... If you want to set a file permission code in Rust, you have to explicitly annotate the code as Unix-only.

Go is already doing that explicit annotation for you. You write the code once, and under the covers, it just works across platforms because it has already helped you with the decision.

> Go's strength is network computing in data centers and it excels at this task, powering these workloads at the world's largest scales. The goroutine-per-request model, Context API, and the standard library inclusion of server infrastructure is testament to this community focus.

From a distance (and not knowing the breadth of needs/use cases of Turborepo), it strikes me as potentially a poor decision in the first place to have picked a language and its ecosystem that is expressly optimized for network-y things.

> Interoperating with these native libraries in Go requires the use of CGO, which switches us from a pure Go toolchain to a much slower C toolchain. Moreover, this switch is a global process, meaning that if we use a single native library, we have to build our entire codebase with CGO

If author is around, can they explain this part in detail? I don't understand how one CGO usage slows everything else

I have a very hard time believing that the choice matters in their context

this is just a build runner, it isn't even the thing doing the builds

Rust is cool and if you just want to get on the bandwagon, its okay to say so, you wouldn't be the first dev to rewrite something "just because" and you won't be the last