> There's a name for what you're doing. It's called "cherry picking". And also there's a name for the act of pulling something out of context to support an arbi

> There's a name for what you're doing. It's called "cherry picking". And also there's a name for the act of pulling something out of context to support an arbitrary point. There's also something called "argument from fallacy". Either refute the points I raised, otherwise there's no point bringing up fallacies :) > Let it be said that I'm not actually a Go but a C programmer, I have been using golang at my current employer for several months now. That being said, that's your experience, and it doesn't necessarily mean that everyone else has your use case. The shorter form is (1) more readable, and (2) less error prone - fact. Less code also means less room to make errors. It was pretty laughable on the golang mailing list when someone asked why there wasn't a max/min implementation for all number types in golang, someone replied why do you need it? You can just implement it yourself like so, and proceeded to write a max implementation where the comparison operator was flipped. It's quite ironic really. > but I guess their idea was that like so many other features, this little syntactic sugar construct does not carry its own weight. It does, it reduces the probability of error by making sure that assignment happens only once. They weigh things very arbitrarily, like how one of the golang authors doesn't think compile checked enums are worth it because hey, they're just enums checked by the compiler to ensure coverage. It shows they don't have experience with other languages, or with features that reduce error rates. > that's hard to believe. Any code samples for illustration? (I invite you to cherry pick!). I already listed the lack of a ternary operator or its equivalent, and this extends to other constructs which can be expressions. Java is getting switch expressions in the upcoming release, and in Kotlin, try/catch is an expression, it's quite nice. The most obvious other one is error handling, "if err != nil" checks everywhere, which makes the code base much longer. Others include the lack of map/fold/etc functions. The code base I work with is littered all over the place with functions to do what effectively are maps or maps+filters. Those functions end up being 8 lines or so, whereas they could be fit in 1-2 lines, inline at the call site, without the reader having to jump to the function implementation. This gets tiring very quickly, and makes it take longer to understand the code at hand. Another example is needing to explicitly assign to a temporary variable if you need to take its address to pass it as an argument. a := foo() b := bar() c := baz() qux(&a, &b, &c) as opposed to for example Rust: qux(&foo(), &bar(), &baz()); or Java qux(foo(), bar(), baz());