←back to thread

“Go’s design is a disservice to intelligent programmers”

(nomad.so)
131 points apta | 4 comments | 25 Mar 15 21:48 UTC | HN request time: 0.772s | source
Show context
carbocation ◴[25 Mar 15 22:12 UTC] No.9266352[source]▶
My summary of the author's points: no generics, inexpressive, no good package manager, procedural.

Of these, caring about the fact that it is procedural seems pure opinion. Lacking a package manager is not really a language issue (PHP's package manager, for example, is not coupled to the core language).

So, we are left with the lack of generics and the lack of expressivity. I'm not deep enough in the weeds to be able to argue pro/con for generics intelligently right now, so I will concede that as a concern that has been raised by many.

The lack of expressivity seems to be an inexorable consequence of the goal of simplicity, so I'm sympathetic. That said, it seems to be a tradeoff acknowledged by Go's authors, not an oversight.

Overall, these points don't convince me of the author's thesis (or, at least, they don't seem to justify the title's degree of inflammation).

replies(5): >>9266432 #>>9266452 #>>9266511 #>>9269687 #>>9281940 #
AlexandrB ◴[25 Mar 15 22:26 UTC] No.9266432[source]▶
I thought the "sum" example was pretty damning. Bug count scales with code length so writing tons of boilerplate code to work around language limitations means you're introducing bugs.
replies(4): >>9266445 #>>9266448 #>>9266915 #>>9267114 #
1. jmtulloss ◴[25 Mar 15 22:29 UTC] No.9266448[source]▶
In my opinion, bug count scales within a code base with code length, but you can't really compare languages and say that the shorter one must contain fewer bugs. A more expressive language means you can cram more bugs in fewer lines.
replies(1): >>9266459 #
2. AlexandrB ◴[25 Mar 15 22:31 UTC] No.9266459[source]▶
Take a look at this: http://programmers.stackexchange.com/questions/185660/is-the...

Bug counts/kloc seem to be consistent across languages.

replies(1): >>9266504 #
3. AlexandrB ◴[25 Mar 15 22:40 UTC] No.9266504[source]▶
To add to this, implementing a bunch of boilerplate often means copy/pasting code. That means you risk introducing mistakes where one copy is wrong[1].

[1] http://www.viva64.com/en/b/0260/

replies(1): >>9267387 #
4. NateDad ◴[26 Mar 15 02:01 UTC] No.9267387{3}[source]▶
You assume that Go's simplicity means you end up copying and pasting a lot of code. This is just not the case. In juju (https://github.com/juju/juju), a ~300kloc project, we have approximately one single type that we've copy & pasted where a generic implementation would have been better (it's a set). And honestly, implementing full set functionality was not even really necessary, someone just felt like doing it.