[helper]

I think this is a great point that indirectly highlights how people are often talking past each other when a go vs rust debate comes up. People work in different problem domains with different constraints and therefore the a good language choice in one domain might be wrong for the other.

I don't think anyone in the go community would suggest you write a browser in go. Ignoring the GC performance issues, just the awkwardness of using cgo would make most go developers shudder.

Likewise there are many problem domains where a GC'ed language works just fine. In these cases it is appropriate to consider other factors when deciding which language to use. Perhaps your team is made up of a bunch of experienced scala developers, scala might be a good choice for you over go or rust. That doesn't mean your good choice is universally applicable to all teams.

Some teams might care more about getting the most value per cpu cycle possible. Other teams might care more about the time it takes to get a new engineer up to speed in the language. Both of these can be valid reasons to choose a specific language.

I guess what I'm trying to say is: "Try to choose the language (and other tools) that best matches your organizations constraints. Don't assume that other teams have the same constraints."