<story><title>Three Months of Go from a Haskeller’s perspective (2016)</title><url>https://memo.barrucadu.co.uk/three-months-of-go.html</url></story><parent_chain><item><author>Philip-J-Fry</author><text>Go is incredibly readable I find. Yes, you tend to find yourself writing a lot of code because of the lack of generics, but that is being fixed as we speak. Generics has a draft and it looks nice from a Go developers perspective.&lt;p&gt;And Go let&amp;#x27;s you communicate by copying. That&amp;#x27;s what a Channel is. Pass a struct and that is copied. Pass a pointer and the pointer is copied. The thing it points to isn&amp;#x27;t copied for glaringly obvious reasons.&lt;p&gt;And what would you suggest is a good alternative for returning multiple parameters. Currently this basically forces you to handle any possible errors and results in software you can very easily reason about.&lt;p&gt;Not sure what you mean about human reviewers needing to check errors.</text></item><item><author>eru</author><text>Go impedes its own readability by encourage or even requiring such huge volumes of code.&lt;p&gt;(And Go ain&amp;#x27;t very good at concurrency.  At least they should have let you mark values as immutable, or communicated entirely via copying like Erlang.)&lt;p&gt;Yes, tuples are a really weird thing with Go.  If they had completely left them, that would be bad but sort of defendable.  But instead they give you a half-baked implementation of some of what tuples do with their &amp;#x27;multiple return types&amp;#x27;.&lt;p&gt;(And multiple return types aren&amp;#x27;t even a good fit for signaling errors.  For error-handling you want to return _either_ the result _or_ the error, in a way that the compiler can check that you handled the error.&lt;p&gt;Instead as far as the types are concerned they are always returning both the result and an error, and human reviewers have to make sure that they are checked properly.)</text></item><item><author>TeeWEE</author><text>Go is a programming language for teams, not primarily designed to impress individual programmers...&lt;p&gt;I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you..&lt;p&gt;Yeah its a dumb language, missing a  lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is build for readability, not for writing code fast and elegantly...&lt;p&gt;Often short dense code with complex types is just really hard to read for your overage joe programmer.&lt;p&gt;We&amp;#x27;re not all computer scientists here.&lt;p&gt;Go is designed to write maintainable server side programs that can utilize concurrency in computer these days. Therefore they left out generics... I hope its coming.
I do wish error handling and generics where part of the language... And a tuple type indeed.</text></item></parent_chain><comment><author>np_tedious</author><text>Every isolated Go piece is pretty readable. The problem is that getting most things done requires enough code that it&amp;#x27;s a lot of work to take it all in. Run all the for loops in your head. Etc. Higher level (and esp FP) languages like Haskell or Scala will be the opposite. That bunch of function compositions may take a little bit of work to digest, but once you understand it you understand a lot.&lt;p&gt;When people disagree on readability its often bc they mean two different things. We would benefit from different terms for readable-in-the-small and readable-in-the-large.</text></comment>
<story><title>Three Months of Go from a Haskeller’s perspective (2016)</title><url>https://memo.barrucadu.co.uk/three-months-of-go.html</url></story><parent_chain><item><author>Philip-J-Fry</author><text>Go is incredibly readable I find. Yes, you tend to find yourself writing a lot of code because of the lack of generics, but that is being fixed as we speak. Generics has a draft and it looks nice from a Go developers perspective.&lt;p&gt;And Go let&amp;#x27;s you communicate by copying. That&amp;#x27;s what a Channel is. Pass a struct and that is copied. Pass a pointer and the pointer is copied. The thing it points to isn&amp;#x27;t copied for glaringly obvious reasons.&lt;p&gt;And what would you suggest is a good alternative for returning multiple parameters. Currently this basically forces you to handle any possible errors and results in software you can very easily reason about.&lt;p&gt;Not sure what you mean about human reviewers needing to check errors.</text></item><item><author>eru</author><text>Go impedes its own readability by encourage or even requiring such huge volumes of code.&lt;p&gt;(And Go ain&amp;#x27;t very good at concurrency.  At least they should have let you mark values as immutable, or communicated entirely via copying like Erlang.)&lt;p&gt;Yes, tuples are a really weird thing with Go.  If they had completely left them, that would be bad but sort of defendable.  But instead they give you a half-baked implementation of some of what tuples do with their &amp;#x27;multiple return types&amp;#x27;.&lt;p&gt;(And multiple return types aren&amp;#x27;t even a good fit for signaling errors.  For error-handling you want to return _either_ the result _or_ the error, in a way that the compiler can check that you handled the error.&lt;p&gt;Instead as far as the types are concerned they are always returning both the result and an error, and human reviewers have to make sure that they are checked properly.)</text></item><item><author>TeeWEE</author><text>Go is a programming language for teams, not primarily designed to impress individual programmers...&lt;p&gt;I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you..&lt;p&gt;Yeah its a dumb language, missing a  lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is build for readability, not for writing code fast and elegantly...&lt;p&gt;Often short dense code with complex types is just really hard to read for your overage joe programmer.&lt;p&gt;We&amp;#x27;re not all computer scientists here.&lt;p&gt;Go is designed to write maintainable server side programs that can utilize concurrency in computer these days. Therefore they left out generics... I hope its coming.
I do wish error handling and generics where part of the language... And a tuple type indeed.</text></item></parent_chain><comment><author>LandR</author><text>&amp;gt; Go is incredibly readable I find.&lt;p&gt;I&amp;#x27;m the opposite, I don&amp;#x27;t find it readable at all.&lt;p&gt;I find Go too verbose to be readable.</text></comment>