<story><title>The ecosystem of the Go programming language</title><url>https://henvic.dev/posts/go/</url></story><parent_chain><item><author>hnlmorg</author><text>&amp;gt; &lt;i&gt;Ignore comments about how go is simple to write. There&amp;#x27;s a fair amount of bad go code and people break rules all the time.&lt;/i&gt;&lt;p&gt;This is one of the most famous straw man arguments made in software development and I&amp;#x27;ve seen it used against a plethora of different programming languages -- each time completely missing the point that you can get bad developers writing bad code in any language. The fact it happens in Go isn&amp;#x27;t a testament not to how difficult it is but rather how good of a job the language has done attracting newer developers.&lt;p&gt;&amp;gt; &lt;i&gt;Go is not a simple language. Please learn from my mistakes, and ignore arbitrary metrics like how go has fewer keywords. The complexity doesn&amp;#x27;t go away, it&amp;#x27;s hidden away somewhere.&lt;/i&gt;&lt;p&gt;I completely disagree. Having fewer keywords does make Go simpler to learn and simpler to read other peoples code. The opinionated nature of Go also makes it simpler to collaborate.&lt;p&gt;Writing software isn&amp;#x27;t simple but that complexity of turning ideas into code doesn&amp;#x27;t change significantly from one language to another (generally speaking). You still have to solve a problem using logic and functions. I find the harder problems with software development is collaboration (eg ensuring everyone is following the same coding styles) and reading back old code. Go makes those things easier than some -- not all but definitely some -- languages.&lt;p&gt;I say this based on 30 years of experience writing software in more than a dozen different programming languages.</text></item><item><author>preommr</author><text>Go is not a simple language. Please learn from my mistakes, and ignore arbitrary metrics like how go has fewer keywords. The complexity doesn&amp;#x27;t go away, it&amp;#x27;s hidden away somewhere.&lt;p&gt;If anybody wants to learn go, ignore everything about how easy it is to learn. Because it&amp;#x27;s extremely deceptive. Take time to actually read through a lot of the important underlying concepts like how slices work.&lt;p&gt;Ignore comments about how go is simple to write. There&amp;#x27;s a fair amount of bad go code and people break rules all the time. From official sdks to standard libs. Go can be extremely difficult to both write and read. It&amp;#x27;s implicit interfaces and judicious abuse of interface{} can make tracing how a library is supposed to work a PITA. Writing go can be difficult because of a lack of some language constructs that leave you unsure how to proceed.&lt;p&gt;If you can, use goland. I use vscode and it&amp;#x27;s... not pretty. Almost every single thread I&amp;#x27;ve seen on reddit recommends goland. My experience with vscode has been very unpleasant, particularly with go plus.&lt;p&gt;OTOH, things like criticisms about it&amp;#x27;s error handling are overblown. At best it&amp;#x27;s a mild nuisance, and more often than not, a good thing that makes error handling explicit and clear.&lt;p&gt;There are many things about go that have made me appreciate it&amp;#x27;s existence. There are also many things that have left me absolutely baffled at how bad it is.</text></item></parent_chain><comment><author>TheDong</author><text>&amp;gt; Having fewer keywords does make Go simpler to learn and simpler to read other peoples code&lt;p&gt;Go carefully touts how few reserved keywords it has, but I think it would actually be a simpler to reason about language if it had more reserved keywords.&lt;p&gt;For example, you may notice that &amp;quot;true&amp;quot;, &amp;quot;false&amp;quot;, &amp;quot;len&amp;quot;, &amp;quot;new&amp;quot;, etc all aren&amp;#x27;t reserved keywords.&lt;p&gt;This sometimes does lead to bugs, for example someone may make a function, like &amp;quot;func memoize(new func(...interface{}) interface{}) func(...interface{}) interface{}&amp;quot;, which shadows a common builtin function with a function argument.&lt;p&gt;Usually, the above leads to a compiler error when you try to use the &amp;quot;copy&amp;quot; argument (a value) as a function, but every once in a while, you end up with a type-compatible shadow, at which point things can really break.&lt;p&gt;It would be less confusing if things like &amp;quot;new&amp;quot;, &amp;quot;len&amp;quot;, &amp;quot;copy&amp;quot;, and &amp;quot;true&amp;quot; were keywords, rather than builtins that someone may accidentally alias and shadow.&lt;p&gt;If you account for things like rather essential builtins as well, go&amp;#x27;s list of keywords starts to look far less impressive, and on-par with java or C#.</text></comment>
<story><title>The ecosystem of the Go programming language</title><url>https://henvic.dev/posts/go/</url></story><parent_chain><item><author>hnlmorg</author><text>&amp;gt; &lt;i&gt;Ignore comments about how go is simple to write. There&amp;#x27;s a fair amount of bad go code and people break rules all the time.&lt;/i&gt;&lt;p&gt;This is one of the most famous straw man arguments made in software development and I&amp;#x27;ve seen it used against a plethora of different programming languages -- each time completely missing the point that you can get bad developers writing bad code in any language. The fact it happens in Go isn&amp;#x27;t a testament not to how difficult it is but rather how good of a job the language has done attracting newer developers.&lt;p&gt;&amp;gt; &lt;i&gt;Go is not a simple language. Please learn from my mistakes, and ignore arbitrary metrics like how go has fewer keywords. The complexity doesn&amp;#x27;t go away, it&amp;#x27;s hidden away somewhere.&lt;/i&gt;&lt;p&gt;I completely disagree. Having fewer keywords does make Go simpler to learn and simpler to read other peoples code. The opinionated nature of Go also makes it simpler to collaborate.&lt;p&gt;Writing software isn&amp;#x27;t simple but that complexity of turning ideas into code doesn&amp;#x27;t change significantly from one language to another (generally speaking). You still have to solve a problem using logic and functions. I find the harder problems with software development is collaboration (eg ensuring everyone is following the same coding styles) and reading back old code. Go makes those things easier than some -- not all but definitely some -- languages.&lt;p&gt;I say this based on 30 years of experience writing software in more than a dozen different programming languages.</text></item><item><author>preommr</author><text>Go is not a simple language. Please learn from my mistakes, and ignore arbitrary metrics like how go has fewer keywords. The complexity doesn&amp;#x27;t go away, it&amp;#x27;s hidden away somewhere.&lt;p&gt;If anybody wants to learn go, ignore everything about how easy it is to learn. Because it&amp;#x27;s extremely deceptive. Take time to actually read through a lot of the important underlying concepts like how slices work.&lt;p&gt;Ignore comments about how go is simple to write. There&amp;#x27;s a fair amount of bad go code and people break rules all the time. From official sdks to standard libs. Go can be extremely difficult to both write and read. It&amp;#x27;s implicit interfaces and judicious abuse of interface{} can make tracing how a library is supposed to work a PITA. Writing go can be difficult because of a lack of some language constructs that leave you unsure how to proceed.&lt;p&gt;If you can, use goland. I use vscode and it&amp;#x27;s... not pretty. Almost every single thread I&amp;#x27;ve seen on reddit recommends goland. My experience with vscode has been very unpleasant, particularly with go plus.&lt;p&gt;OTOH, things like criticisms about it&amp;#x27;s error handling are overblown. At best it&amp;#x27;s a mild nuisance, and more often than not, a good thing that makes error handling explicit and clear.&lt;p&gt;There are many things about go that have made me appreciate it&amp;#x27;s existence. There are also many things that have left me absolutely baffled at how bad it is.</text></item></parent_chain><comment><author>preommr</author><text>&amp;gt; This is one of the most famous straw man arguments made in software development and I&amp;#x27;ve seen it used against a plethora of different programming languages -- each time completely missing the point that you can get bad developers writing bad code in any language.&lt;p&gt;This is a fair point since I wasn&amp;#x27;t very clear, and I am talking about something that&amp;#x27;s fairly subjective and abstract. I think the more claims a language makes, the more open it is to failure. I just googled is &amp;quot;rust difficult to learn&amp;quot;, and the first answer is &amp;quot;no&amp;quot;. It&amp;#x27;s all relative, but I am sure that most of us have heard that rust does have a steep learning curve. The only other language that I can think of that advertises itself as easy is python. And I think it has a lot of faults in those claims too. But python does a much better job of being easy than go does. It&amp;#x27;s completely different leagues.&lt;p&gt;Again, this is a messy point to make, either somebody understand what I am trying to say or they should leave it at that because trying to qualify ideas like this is fuitless.&lt;p&gt;&amp;gt; I completely disagree. Having fewer keywords does make Go simpler to learn and simpler to read other peoples code.&lt;p&gt;I really don&amp;#x27;t think skipping keywords like public and using casing makes things simpler. A quick google search shows that go has 6 less keywords than c. I mean, c&amp;#x27;mon...&lt;p&gt;&amp;gt; I say this based on 30 years of experience writing software in more than a dozen different programming languages.&lt;p&gt;If you&amp;#x27;ve had years of experience in old school c&amp;#x2F;cpp, then (I would assume) go will be a lot easier, and a lot better in comparison.</text></comment>