IMO - just because a company owns the domain doesn't mean they control the language. You need someone to own the domain, and it's always preferable if they are

IMO - just because a company owns the domain doesn't mean they control the language. You need someone to own the domain, and it's always preferable if they are part of a company that won't disappear anytime soon. Similarly being able to unlist someone with powers isn't enough. If I pushed a commit replacing the Rust core team members with someone else it may go through, but nobody in the community will think that was legitimate and it would be reverted. Same with Go, surely. - If Go has a defined governance model you can't say that Google controls it. If it's wishy-washy then you can't tell. IIRC it's wishy washy right now but ICBW, the last time I was doing go was a year ago. However, it's not clear that Google forced this type alias thing to happen. -type aliases are a useful feature even without Google's use case. They might be a broken solution to Google's problem but they solve a lot of other things. Dave Herman once gave a talk about "The Great Int Debate" in Rust. The core team had made a decision (pre 1.0) that many folks disagreed with, leading to resentment. The process was improved with a few rules both participants and decision makers had to abide by, and the re-discussion was more productive. The final decision was a different one, but everyone was happy with it. This evolved into the current set of processes for Rust's rfc process and is going strong. https://air.mozilla.org/friday-plenary-rust-and-the-community/ https://air.mozilla.org/friday-plenary-rust-and-the-communit... Go might want to look into governance models like these if they truly are a problem. From one blog post, I can't really tell.