3 ms·

This was a terribly worded blog post. The problems the author faced with go were so paper thin -- I don't think they warranted claiming "every line of go i've w

This was a terribly worded blog post. The problems the author faced with go were so paper thin -- I don't think they warranted claiming "every line of go i've written is now deprecated". It's pretty clear going into go from the initial HelloWorld -- that you are expected to: 1 - use gofmt 2 - won't have inheritance 3 - Drudge your way through a solution for dependency versioning To complain about it so late into a project really speaks poorly to the author.

djrogers 9y ago
> To complain about it so late into a project really speaks poorly to the author. There's really no need for such a personal attack here - why do you feel a need to lash out at this author? It is entirely reasonable to start a project knowing of limitations, and finish that project with a better understanding of how those limitations affect your productivity in the real world. That's what we call experience, and learning from it is a critical element of personal growth.
- zemo 9y ago
  > There's really no need for such a personal attack here - why do you feel a need to lash out at this author? the whole blog post is lashing out at something. You reap what you sow. There's no "these are the tradeoffs, and this is why I disagree with those tradeoffs"; every argument goes like this: - I have an expectation - that expectation is informed by my priors, not by Go - Go didn't meet my expectations - even though Go never made or promised to meet those expectation, I'm going to be mad that it didn't do something that I wanted that was never promised the whole article is structured like "Go wants me to think in a different way than I already think and I refuse to think in a new way".
  - matthewmacleod 9y ago
    I don't think that's fair. More – "Go suggested I think in a different way, then I did it and it still wasn't good like it was advertised, and now I'm going"
  - emperorcezar 9y ago
    That's not it at all. He attacked your chosen tribe, now you're responding with personal attacks. The correct response would be, "I didn't mean to personally attack him, what I meant was X" Go is a language, attacking Go is not justification for you to attack the author. Replace Go with a rant about Ford trucks and you'll see how silly you are being.
0xCMP 9y ago
Yes, in go these things have solutions. Maybe not the best ones we can have, but there are ways to approach the problems beyond just giving up. 1 - Most editors automatically support that. I wouldn't say being forced to follow a certain code convention is bad, but it understandable that it may bother some people. 2 - You can still the code-reuse features of inheritance by using embedded structures with methods attached to them. 3 - There are many solutions which solve the problem without needing to commit the vendor directory to git like `glide`.

djrogers 9y ago

> To complain about it so late into a project really speaks poorly to the author. There's really no need for such a personal attack here - why do you feel a need to lash out at this author? It is entirely reasonable to start a project knowing of limitations, and finish that project with a better understanding of how those limitations affect your productivity in the real world. That's what we call experience, and learning from it is a critical element of personal growth.

zemo 9y ago
> There's really no need for such a personal attack here - why do you feel a need to lash out at this author? the whole blog post is lashing out at something. You reap what you sow. There's no "these are the tradeoffs, and this is why I disagree with those tradeoffs"; every argument goes like this: - I have an expectation - that expectation is informed by my priors, not by Go - Go didn't meet my expectations - even though Go never made or promised to meet those expectation, I'm going to be mad that it didn't do something that I wanted that was never promised the whole article is structured like "Go wants me to think in a different way than I already think and I refuse to think in a new way".
- matthewmacleod 9y ago
  I don't think that's fair. More – "Go suggested I think in a different way, then I did it and it still wasn't good like it was advertised, and now I'm going"
- emperorcezar 9y ago
  That's not it at all. He attacked your chosen tribe, now you're responding with personal attacks. The correct response would be, "I didn't mean to personally attack him, what I meant was X" Go is a language, attacking Go is not justification for you to attack the author. Replace Go with a rant about Ford trucks and you'll see how silly you are being.

0xCMP 9y ago

Yes, in go these things have solutions. Maybe not the best ones we can have, but there are ways to approach the problems beyond just giving up. 1 - Most editors automatically support that. I wouldn't say being forced to follow a certain code convention is bad, but it understandable that it may bother some people. 2 - You can still the code-reuse features of inheritance by using embedded structures with methods attached to them. 3 - There are many solutions which solve the problem without needing to commit the vendor directory to git like `glide`.