3 ms·

I kind of read the original argument that Go is dominated by a "Google point of view", and there really isn't a significant alternative view that's as coherent.

I kind of read the original argument that Go is dominated by a "Google point of view", and there really isn't a significant alternative view that's as coherent. And that may be a risk. It's not obvious to figure out how Go "plays with others". And it's unclear if that's much of a risk or not. As an outsider, you read of the funky module system duality and you wonder... "What if I don't want to 'work like Google'? Will this work in the future?" It's actually not that clear. It's weird, because I don't get this sense, for example, with Kotlin projects in Android. You can write Kotlin in Android Studio. Or, in IntelliJ for backend code with Spring. And the tooling seems to be oriented in the same way. For most devs I've met, you can just swap Kotlin for Java, and everything else just works the same, and they don't get lost. You never have this sense of "well... _Google_ does it _this_ way..." when it comes to the tooling.

tomnipotent 7y ago
> And that may be a risk. How is it a risk? Is Rust at risk because of Mozilla? What about Java given all its corporate sponsors? People need to stop with this predictive FUD crap, it's tiring.
- hu3 7y ago
  It's mesmerizing to observe the lengths that people can go when trying to smear an open-source tool. I can't even fathom the amount of relentless bullshit that teams of big projects have to endure.
- mr_tristan 7y ago
  It _might_ be an institutional risk for people, who are evaluating tooling, to just decide that they don't see other major companies getting involved, see a bunch of gripes about the module system switcheroo, and decide "nah". You really get a sense of "this is Google's approach" with the go toolchain, because it's pretty unique. One of the first documents, "How to Write Go Code", sets up a workspace that doesn't clearly integrate in with any other toolchain I'm aware of. So, just by reading about the ecosystem, it's not clear who is really investing in it, and, you have a single, unique approach to tooling apparently dominating. I just wonder if these arguments would be mitigated if Go ever got the investment in "developer relations" that other Google projects get, with some better onboarding documentation.
- leshow 7y ago
  Rust isn't really a fair comparison, not anymore anyway, it's very much a community led project.
skybrian 7y ago
That seems like a special case. Kotlin swaps in easily because it was designed to be compatible with Java, and you've bought into the Java ecosystem already. For someone coming from a different ecosystem, it would be a big jump.
- mr_tristan 7y ago
  It's just interesting because Android seems to be much more "externally focused", as opposed to Go, which seems much more of "here's an internal tool you can use". Kotlin and the community version of IntelliJ came along _way after_ the Android toolchain was already available, and Google basically shifted gears and adopted it. Android Studio switched from Eclipse to IntelliJ, and Kotlin is now a default language. I just don't see that kind of change ever happening with Go. There's no "other voice". It feels like it's "Google with a few enthusiasts".

tomnipotent 7y ago

> And that may be a risk. How is it a risk? Is Rust at risk because of Mozilla? What about Java given all its corporate sponsors? People need to stop with this predictive FUD crap, it's tiring.

hu3 7y ago
It's mesmerizing to observe the lengths that people can go when trying to smear an open-source tool. I can't even fathom the amount of relentless bullshit that teams of big projects have to endure.
mr_tristan 7y ago
It _might_ be an institutional risk for people, who are evaluating tooling, to just decide that they don't see other major companies getting involved, see a bunch of gripes about the module system switcheroo, and decide "nah". You really get a sense of "this is Google's approach" with the go toolchain, because it's pretty unique. One of the first documents, "How to Write Go Code", sets up a workspace that doesn't clearly integrate in with any other toolchain I'm aware of. So, just by reading about the ecosystem, it's not clear who is really investing in it, and, you have a single, unique approach to tooling apparently dominating. I just wonder if these arguments would be mitigated if Go ever got the investment in "developer relations" that other Google projects get, with some better onboarding documentation.
leshow 7y ago
Rust isn't really a fair comparison, not anymore anyway, it's very much a community led project.

skybrian 7y ago

That seems like a special case. Kotlin swaps in easily because it was designed to be compatible with Java, and you've bought into the Java ecosystem already. For someone coming from a different ecosystem, it would be a big jump.

mr_tristan 7y ago
It's just interesting because Android seems to be much more "externally focused", as opposed to Go, which seems much more of "here's an internal tool you can use". Kotlin and the community version of IntelliJ came along _way after_ the Android toolchain was already available, and Google basically shifted gears and adopted it. Android Studio switched from Eclipse to IntelliJ, and Kotlin is now a default language. I just don't see that kind of change ever happening with Go. There's no "other voice". It feels like it's "Google with a few enthusiasts".