4 ms·

> - Most declarations, including method declarations, take place at the top level. This is unlike most languages which declare methods one level indented along

by apta 7y ago

> - Most declarations, including method declarations, take place at the top level. This is unlike most languages which declare methods one level indented along with the object's fields. You can do the same in C++ or Kotlin, etc., but you don't find people saying that those automatically make lines shorter. > - Short type definitions (`type T1 T2`) are encouraged and often used for any repeated non-scalar type. This shortens argument specifications and (if a good name was chosen) improves readability. Also possible in C++ or Kotlin, among others. > - Anonymous struct fields are shorter both to declare and use. In class-based OO this is often the case for subclasses but not wrappers/facades. Go's approach covers both. This can save lines of code (at the expense of not being able to easily figure out what classes implement or embed other classes or interfaces), but does nothing to shorten lines of code. Same applies to error handling. Returning early can be useful in certain situations, but cause readability issues in others. golang linters did a bad job here as you point out.

morelisp 7y ago
> You can do the same in C++ or Kotlin, etc., but you don't find people saying that those automatically make lines shorter. I don't know what happens in the Kotlin community, but you absolutely find people saying C++ is "less nested" than Java/Python/JavaScript/etc (and claiming it as an advantage and disadvantage depending on their viewpoint). I don't know what you're really arguing with here. Go gives you a construct that makes lines shorter than most other OO languages. It's not "automatic" as it's a feature of the language someone had to design - but regardless it is shorter. > [Short type definitions are] possible in C++ or Kotlin, among others. Again I don't know Kotlin, but no, it's not possible in C++ (at least up through the 11-and-a-bit I work with). The equivalent C++ would be "struct T1 : public T2", plus another line of "{}". And it's rare (for good-ish reasons) to subclass specializations of the default containers rather than wrap them. > [An anonymous structure] does nothing to shorten lines of code. I don't see how this is a debatable point. Not having to specify the field name in the definition is a shorter line than than having to specify it, strictly so. Not having to specify the full path to such an embedded object to call a method or access a field is nearly always shorter (it can be longer if your struct name is longer than your field name would have been and you have an ambiguous resolution - the former happens a lot, the second less, and both in combination even less). > Returning early can be useful in certain situations, but cause readability issues in others. Regardless, it keeps the lines short. You seem to want to argue "Go is ugly", which, fine. But the claim was "Go doesn't do anything to help make shorter lines." It does quite a bit.

by apta 7y ago

morelisp 7y ago

> You can do the same in C++ or Kotlin, etc., but you don't find people saying that those automatically make lines shorter. I don't know what happens in the Kotlin community, but you absolutely find people saying C++ is "less nested" than Java/Python/JavaScript/etc (and claiming it as an advantage and disadvantage depending on their viewpoint). I don't know what you're really arguing with here. Go gives you a construct that makes lines shorter than most other OO languages. It's not "automatic" as it's a feature of the language someone had to design - but regardless it is shorter. > [Short type definitions are] possible in C++ or Kotlin, among others. Again I don't know Kotlin, but no, it's not possible in C++ (at least up through the 11-and-a-bit I work with). The equivalent C++ would be "struct T1 : public T2", plus another line of "{}". And it's rare (for good-ish reasons) to subclass specializations of the default containers rather than wrap them. > [An anonymous structure] does nothing to shorten lines of code. I don't see how this is a debatable point. Not having to specify the field name in the definition is a shorter line than than having to specify it, strictly so. Not having to specify the full path to such an embedded object to call a method or access a field is nearly always shorter (it can be longer if your struct name is longer than your field name would have been and you have an ambiguous resolution - the former happens a lot, the second less, and both in combination even less). > Returning early can be useful in certain situations, but cause readability issues in others. Regardless, it keeps the lines short. You seem to want to argue "Go is ugly", which, fine. But the claim was "Go doesn't do anything to help make shorter lines." It does quite a bit.