4 ms·
(Kind of meta-venting out below, also known as rant.) 1. I don't know why I find Russ's writings are so irksome, even unpleasant to read, sorry. (Please help m
by tandr 7y ago
(Kind of meta-venting out below, also known as rant.)
1. I don't know why I find Russ's writings are so irksome, even unpleasant to read, sorry. (Please help me on that, maybe I am in "questioning authority" mode and cannot flip out of it.) I cannot shake that feeling of being patronized all the time without being asked. The whole article, no - bunch of his posts, - reads like "we know better". Is it a Google thing, or heavy Rob Pike's influence?
Yes, he is bringing some good points, and some very questionable ones. And for the questionable one (Compatibility section for example, or SAT solver question (nobody did it before?), or version naming, or paths for the sub-components...) it feels like he is trying to push explanation about his (and his team?) reasons and motivations behind these decisions, but... it is a monologue. There are more opinions and whole wide world of different software shops with own ideas and practices.
2. Go2 was a promised land, that later translated into "incremental, no code
breaking" approach. Nowadays it feels like they are not even talking about it anymore!
Looking at general history of programming languages, pretty much every language has had it's "C++" or Modula-2 moments. It is a natural process - an evolution - when unneeded parts disappear, and useful ideas added/extended. Amount of gotchas in Go is not zero, and to me (YMMV) it feels like Go2 would be (was?) a good time to shake off under-thought items, and enforce some new rules. Maybe even add interoperability between .go and .go2 files, maybe even semi-automatic upgrade path to run `go2 fmt ` on old files a la to Kotlin from Java - I don't know. But it feels like an opportunity and momentum for a "peaceful revolution" is lost.
3. Even with non-breaking changes style of change they have managed to break stuff. I, for one, still sit on 1.12 branch - because when I tried to upgrade to 1.13 (twice now), and our pure-Go code just plainly did not build with some obscure messages (I think it was linking or module cache errors). So, why pretend? Code rot is unavoidable - do we like it or not.
99. There are couple more points about chilling effect of "we know better" on a community as whole. (One example would be this whole "error" debacle that visible reduced activity on issue tracker and golang-nuts mailing lists after "hey all, we are going this way because we already went there". Immediately after it felt like people just gave up and left. "Empty town square" feeling.) It would be interesting to see this year results of "the state of Go" survey, but I don't think we will see a worrisome drops there -- the amount of new people coming in would easily override any opinions of people leaving.
/end of rant, sorry for a long post
- IshKebab 7y agoI think you're wrong on all counts (or I have no idea what you're trying to say). > nobody did it before? As far as I know no other dependency system is the same as Go's. > "we know better" I mean, it is Rob Pike. How successful do you have to be before you get to say I know better? In this case it is better. > Nowadays it feels like they are not even talking about Go 2 anymore! This very post is about Go 2 (in the sense that there was ever going to be a "Go 2"). > pretty much every language has had it's "C++" or Modula-2 moments. It is a natural process - an evolution - when unneeded parts disappear, I can count on one finger the number of parts that have disappeared from C++.
- mfer 7y agoGo modules are in the post Rob Pike era. Russ Cox is how the sole lead of Go and this was his project
- skybrian 7y agoUnfortunately, I'm not sure if there's any more polite way for Russ to say that he still thinks he's right. He's gone into enormous detail about how he's closely studied what other people have done and still thinks he's right. When that's the bottom-line message, I don't see how to get it across without it seeming irksome to people who see him as an authority figure to be resisted? A project's leaders are always going to opinions about how things should work, and they can do a lot to listen better and understand other people's concerns, but they're still not going to choose somebody else's solution if they're not actually convinced it's better. Choosing the solution you think is actually worse on an important issue like this is basically a recipe for self-sabotage. I think oftentimes people have unrealistic expectations of how open source software works. It's not a democracy. There's no way to win without actually convincing the project owners that your way is better.