|
|
|
|
|
|
by richbell
1259 days ago
|
|
|
> Yet another whiner complaining about well-known problems that advanced users are aware of doesn't add anything and nothing in this article is new thing to any advanced user. "Well-known problems that advanced users are aware of", in other words problems that you can and will shoot yourself in the foot with unless you've already shot yourself in the foot and know to avoid them? Why is it contentious to say that things should and could be better? > Especially if the asshole behind article makes the title extra confrontational and aggressive just to piss off people. Why do you feel the need to reproach constructive criticism as being from assholes and "whiners"? You can like Go, or anything else, while acknowledging its flaws and believing it should be better. I thoroughly enjoy Kotlin, TypeScript, and a handful of other technologies but I will be the first to admit and lament their failings. (I'll admit the title is cheeky/provocative, but I think calling the author an asshole and ascribing intent that they want to piss people off says more about you than them.) |
|
|
>"Well-known problems that advanced users are aware of", in other words problems that you can and will shoot yourself in the foot with unless you've already shot yourself in the foot and know to avoid them?
Not really. For example the mutex copying will be caught by tooling
and majority of problems can be summed up "it makes writing some code more annoying and verbose", not "introduces subtle and hard to find errors"If you read the actual article you'd know that's what author complained most about, annoyances (and I pretty much agree with most of it).
The biggest "trap" being probably not being able to have proper immutable types but honestly so far that haven't bitten me in any way; the argument presented in article shows it off in really stupid way too, I'd think anyone assumes methods on a type (especially ones named Change()) would modify it by default and if you dont want caller to mutate it you wouldn't pass reference in the first place.
Better example would be passing a struct that have nested references as that would be a bit questionable as passing struct shallow copies it, but not the deeper levels that could be changed by the caller, so when bad enough coding practices were applied it might lead to something funny
Some other sorta-footgun is lack of timeouts on http/tcp calls (technically stdlib footgun) which means carelessly written code might get into bad behaviour, and the fact that map does not shrink (but that's implementation footgun) so long lived map will have max size it seen on its lifetime.