<story><title>Go Turns 10</title><url>https://blog.golang.org/10years</url></story><parent_chain><item><author>srparish</author><text>+ By declaring a field&amp;#x2F;variable []Thing vs []*Thing you get different for loop semantics. Way to easy to think your mutating the array item, but only mutating a local copy or vice versa. If you change the field&amp;#x2F;variable you need to audit all your code to make sure you haven&amp;#x27;t broken things.&lt;p&gt;+ gofmt feels way out of date. These days clang-format (c++), prettier (typescript), black (python), scalafmt (scala) take care of wrapping&amp;#x2F;unwrapping lines such as function definitions or function calls. They basically cover all formatting needs so you never have to manually format anything.&lt;p&gt;+ Scope of element in for-range loop isn&amp;#x27;t right, so capturing that scope in a lambda does the wrong thing with no warning.&lt;p&gt;+ Encourages use of indexes; which is error prone, most modern languages allow writing most code without needing indexes using map&amp;#x2F;filter&amp;#x2F;reduce or comprehensions.&lt;p&gt;+ No help from type-system for use of pointer without nil check.&lt;p&gt;+ Very easy to get nils in places one would hope to be able to prohibit them in. EG Using pointer as a poor man&amp;#x27;s unique_ptr&amp;lt;&amp;gt; means that I also get optional&amp;lt;&amp;gt; symantics (without the type checking) when I don&amp;#x27;t want or expect such. Also allows for aliasing when I don&amp;#x27;t want or expect such.&lt;p&gt;+ Difference between &amp;#x27;=&amp;#x27; and &amp;#x27;:=&amp;#x27; is silly, especially since &amp;#x27;:=&amp;#x27; can be used to reassign values. Even more frustrating that &amp;#x27;:=&amp;#x27; creates shadowing in nested scopes, so doesn&amp;#x27;t always do what one would expect it would do, such as accidentally creating a shadowed &amp;#x27;err&amp;#x27; that doesn&amp;#x27;t get checked.&lt;p&gt;+ if&amp;#x2F;switch should be allowed to be expressions, allowing much safer single-expression initialization of variables, rather then requiring default initialization and mutation, which is much easier to get wrong.</text></item><item><author>badrequest</author><text>Any specific complaints, or did you just feel like calling us all cavedwellers?</text></item><item><author>timothycrosley</author><text>And yet it still feels like a language out of the 60s or 70s. To me, Go feels like the programming language equivalent of insisting that everyone communicate just by grunting because it&amp;#x27;s less complex to teach people just grunting than it is to teach them more effective forms of communication. And in theory, they still can communicate all the same things with more grunting! Some people refer to this as simplicity, and in a way it is, but it&amp;#x27;s simplicity in the language constructs at the expense of more complexity in the usage of the language to form more complex thoughts. There must be a golden balance here, but I don&amp;#x27;t feel like Go is it for all the fanfare it has been getting lately.</text></item></parent_chain><comment><author>Strom</author><text>&amp;gt; &lt;i&gt;By declaring a field&amp;#x2F;variable []Thing vs []&lt;/i&gt;* &lt;i&gt;Thing you get different for loop semantics. Way to easy to think your mutating the array item, but only mutating a local copy or vice versa.&lt;/i&gt;&lt;p&gt;The loop semantics are always the same, the element variable is a copy of the value at the current index. Yes that means that if the value is a pointer, the copy of that pointer can be used to modify the pointed data. This is something a good Go programmer should understand well because this behavior goes way beyond for loops. For example functions - &lt;i&gt;func (t Thing)&lt;/i&gt; vs &lt;i&gt;func (t&lt;/i&gt; * &lt;i&gt;Thing)&lt;/i&gt; - with the pointer version the body of the function can modify the pointed data. Side-effects! Just like the for loop.&lt;p&gt;&amp;gt; &lt;i&gt;gofmt feels way out of date.&lt;/i&gt;&lt;p&gt;I like to think of it as stable. The biggest strength of gofmt is how universal it is. Everyone uses it and all code out there looks the same. There&amp;#x27;s a growing collection of Go code out there. If gofmt would keep changing its style, then all the already published code would no longer match the standard. Thus, I think there needs to be a real strong reason to modify anything about it.</text></comment>
<story><title>Go Turns 10</title><url>https://blog.golang.org/10years</url></story><parent_chain><item><author>srparish</author><text>+ By declaring a field&amp;#x2F;variable []Thing vs []*Thing you get different for loop semantics. Way to easy to think your mutating the array item, but only mutating a local copy or vice versa. If you change the field&amp;#x2F;variable you need to audit all your code to make sure you haven&amp;#x27;t broken things.&lt;p&gt;+ gofmt feels way out of date. These days clang-format (c++), prettier (typescript), black (python), scalafmt (scala) take care of wrapping&amp;#x2F;unwrapping lines such as function definitions or function calls. They basically cover all formatting needs so you never have to manually format anything.&lt;p&gt;+ Scope of element in for-range loop isn&amp;#x27;t right, so capturing that scope in a lambda does the wrong thing with no warning.&lt;p&gt;+ Encourages use of indexes; which is error prone, most modern languages allow writing most code without needing indexes using map&amp;#x2F;filter&amp;#x2F;reduce or comprehensions.&lt;p&gt;+ No help from type-system for use of pointer without nil check.&lt;p&gt;+ Very easy to get nils in places one would hope to be able to prohibit them in. EG Using pointer as a poor man&amp;#x27;s unique_ptr&amp;lt;&amp;gt; means that I also get optional&amp;lt;&amp;gt; symantics (without the type checking) when I don&amp;#x27;t want or expect such. Also allows for aliasing when I don&amp;#x27;t want or expect such.&lt;p&gt;+ Difference between &amp;#x27;=&amp;#x27; and &amp;#x27;:=&amp;#x27; is silly, especially since &amp;#x27;:=&amp;#x27; can be used to reassign values. Even more frustrating that &amp;#x27;:=&amp;#x27; creates shadowing in nested scopes, so doesn&amp;#x27;t always do what one would expect it would do, such as accidentally creating a shadowed &amp;#x27;err&amp;#x27; that doesn&amp;#x27;t get checked.&lt;p&gt;+ if&amp;#x2F;switch should be allowed to be expressions, allowing much safer single-expression initialization of variables, rather then requiring default initialization and mutation, which is much easier to get wrong.</text></item><item><author>badrequest</author><text>Any specific complaints, or did you just feel like calling us all cavedwellers?</text></item><item><author>timothycrosley</author><text>And yet it still feels like a language out of the 60s or 70s. To me, Go feels like the programming language equivalent of insisting that everyone communicate just by grunting because it&amp;#x27;s less complex to teach people just grunting than it is to teach them more effective forms of communication. And in theory, they still can communicate all the same things with more grunting! Some people refer to this as simplicity, and in a way it is, but it&amp;#x27;s simplicity in the language constructs at the expense of more complexity in the usage of the language to form more complex thoughts. There must be a golden balance here, but I don&amp;#x27;t feel like Go is it for all the fanfare it has been getting lately.</text></item></parent_chain><comment><author>gameswithgo</author><text>I actually like Go&amp;#x27;s simplicity a lot, it was very easy for me to learn and very easy to programming with it because of that. But I agree strongly with some of your points.  = vs := specifically feels like a plain mistake, and even against Go philosophy of having just 1 way to do things.&lt;p&gt;I think any new language should be designed around options instead of nils.  F#, Rust, Zig show different ways to do this, and often any performance penalty can be compiled away.&lt;p&gt;if&amp;#x2F;switch being expressions is a simple and helpful idea, languages should allow this.&lt;p&gt;using map&amp;#x2F;filter&amp;#x2F;reduce as the idiomatic way to do things I am less sure about. This can come in handy but also would add a lot of complexity to Go, and in most languages these have a performance penalty.&lt;p&gt;its important to remember that not all programmers are interested in languages, they just want to get their project done.  So being able to hop into a code base and have low cognitive overhead, because there are no mysterious features they have to learn, having quick compile times, and explicit semantics can be really helpful there. That can save you more time than typing less because of generics and meta programming sometimes.</text></comment>