He does link to an article [0] that mostly talks about multi-platform Go and uses Rust as a language that doesn't have these problems, to the same degree at least.
The gist of the article is that, while Go might very well compile easily on multiple platforms, it does so not by solving the complexities inherent with this problem but rather by merely hiding them from the user.
There are plenty of examples in the article so I won't elaborate on that part but his examples mostly revolve around $(platform)-specific features being poorly poly-filled on non-$(platform) platforms.
I just read that article, and I'll bet you're right that it represents the (unstated) thinking behind that conclusion. But if so, my conclusion would be different from the author's.
The big picture is that Go programming is intended to be more automated while Rust programming is intended to be more customized (relative to each other). When the automation does what you need, it's more convenient, so it's more useful. When it doesn't, because of some issue or other, Rust's ability to customize is more useful. Go can be customized, too, but it's usually the case that something intended to be automated is harder to customize than something intended to be customized like Rust.
So my conclusion (for just this 2-language comparison) would be, Use Go when its built-in features do what you need. It's easier to build with in that case. Use Rust when you need more optimization of something than you can get out of the box from Go. It's easier to optimize.
I skimmed over that article and most of the criticism is about OS API wrappers. The thing that enables Go's single command cross compilation is thanks to other components of the pipeline being implemented in Go, like the linker, or not needing Windows import libraries (there is a merged RFC for Rust called raw dylibs to solve this, but implementation has stagnated... go has this feature already).
In the long term, Rust may end up in a better place than Go regarding portability but of course as long as GCC can target more than clang and there is no Rust gcc backend while there is a Go backend, Rust can't be better than Go in all portability aspects.
Comments
He does link to an article [0] that mostly talks about multi-platform Go and uses Rust as a language that doesn't have these problems, to the same degree at least.
The gist of the article is that, while Go might very well compile easily on multiple platforms, it does so not by solving the complexities inherent with this problem but rather by merely hiding them from the user.
There are plenty of examples in the article so I won't elaborate on that part but his examples mostly revolve around $(platform)-specific features being poorly poly-filled on non-$(platform) platforms.
[0]: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
I just read that article, and I'll bet you're right that it represents the (unstated) thinking behind that conclusion. But if so, my conclusion would be different from the author's.
The big picture is that Go programming is intended to be more automated while Rust programming is intended to be more customized (relative to each other). When the automation does what you need, it's more convenient, so it's more useful. When it doesn't, because of some issue or other, Rust's ability to customize is more useful. Go can be customized, too, but it's usually the case that something intended to be automated is harder to customize than something intended to be customized like Rust.
So my conclusion (for just this 2-language comparison) would be, Use Go when its built-in features do what you need. It's easier to build with in that case. Use Rust when you need more optimization of something than you can get out of the box from Go. It's easier to optimize.
I skimmed over that article and most of the criticism is about OS API wrappers. The thing that enables Go's single command cross compilation is thanks to other components of the pipeline being implemented in Go, like the linker, or not needing Windows import libraries (there is a merged RFC for Rust called raw dylibs to solve this, but implementation has stagnated... go has this feature already).
In the long term, Rust may end up in a better place than Go regarding portability but of course as long as GCC can target more than clang and there is no Rust gcc backend while there is a Go backend, Rust can't be better than Go in all portability aspects.