There is good reason for such concern. The Go team has a history of deafness to community pain - after all, it took years for them to even really admit there was a problem with `go get`.
Show this thread
-
Now, one *could* make an "ends justify the means" argument - that whatever pain the process might cause, an objectively better result is worth it.
Show this thread
And, to be clear, i think modules are mostly better than dep *as it stands today*. (But, as i said early on, that is not, and never has been, the right comparison) But that brings us around to this tweet.https://twitter.com/_rsc/status/1022165430532747266 …
-
-
If incompatibility is inevitably such a minefield, then it means the arguments implying vgo would *cause* a convergence towards a compatible ecosystem aren't true, and never were.
Show this thread -
These were the arguments i found so problematic. And the "convergence" idea was a main pillar taken up by others https://www.reddit.com/r/golang/comments/8m2zro/vgo_analysis_failure_modes/e0dx77v/ … If these arguments weren't true all along? That's engaging in bad faith.
Show this thread -
So all it leaves is this - Russ doesn't trust SAT enough to use it for automation. Which i get. But now, we're not talking about high-minded design, or hard choices in pursuit of the best outcome, or the most scalable solution for an ecosystem. That's just workflow preferences.
Show this thread -
And workflow preferences generally don't have "right" answers. Picking one over another isn't a good basis for capsizing a community project.
Show this thread -
i've learned a lot from this process. Scars are good teachers. (Though i wouldn't pretend for a moment that i've had the worst 2018 - give
@bketelsen a hug if you see him this week!)Show this thread -
i love communities, and helping them thrive. Those are my values. i've tried hard to keep my trusting, communitarian attitude, in the face of all this.
Show this thread -
Most important, though, is what all this says about the future of Go. No matter your take on the outcome, this process was extraordinarily toxic. We can't chew up and spit out community members on every major change.
Show this thread -
Now, It's important that we embrace creative destruction when necessary. Keeping code around because we want to spare the original authors' feels is a surefire path to collapsing under our own weight.
Show this thread -
But we also can't be cavalier about cutting. Open source contributions are made in good faith, in a spirit of collaboration and openness. Failing to honor that spirit is the best, fastest path to a dried up community.
Show this thread -
i'm glad that Russ seems to be looking to the Rust community for inspiration here. i think they've made a lot of good decisions. https://twitter.com/_rsc/status/1022591963567194112 … However, it doesn't seem like the community should look to Google/the Go team for leadership on good collaboration.
Show this thread -
Go has a real problem with governance. Nothing the Go team "gives" to the community can fundamentally change that. If we, as a community, want to see better process and outcomes, the better governance model will need to come from us. (fin)
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.