<p>I came across these articles by Dave Cheney this morning entitled <a href="https://dave.cheney.net/2017/06/15/simplicity-debt">Simplicity Debt</a> and <a href="https://dave.cheney.net/2017/06/18/simplicity-debt-redux">Simplicity Debt Redux</a>. </p>
<p>Dave makes an argument for generics in Go in the first article; he states how Python missed the boat on concurrent programming, and how it had to play catch up when concurrent programming became more prevalent, because Python’s designers believed concurrent programming wasn’t going to take off. That point sounds familiar to me with the generics in Go arguments.</p>
<p>The second article is more about how generics would change the stdlib and the drawbacks it would have on the language and community as a whole. In Dave’s conclusion to this second article, he states:</p>
<blockquote>
<p>. . . adding generics or immutability has nothing to do with the syntax of those features, little to do with their underlying implementation, and everything to do with the impact on the overall complexity budget of the language and its libraries, that these features would unlock.</p>
</blockquote>
<p>That’s another point I found myself agreeing with after reading the entire article. Sure Go can have generics, plenty of other languages have it, but is it worth it in Go? The language is known for its simplicity and readability.</p>
<p>So, after reading both of those articles I asked myself, why not use Rust, which I see being compared to Go all the time, or C++, to scratch the generics itch? Why not Java? I’m a proponent of, and often read in this very sub, using the right tool for the job. It seems that if a point arises in the design phase where generics would help to simplify the code, then a language with generics should be used. Good, up-front, object oriented design would make sure all major objects and methods would be fleshed out in the beginning to prevent writing code before choosing the implementation language to catch cases for generics.</p>
<p>What are the qualities of Go that you like, that another language doesn’t have, that would be maintained and if and when generics are added to the language and that prevent you from using another language when necessary? Do languages like the aforementioned C++ and Rust not have those qualities? Are you already switching to another language with generics as a stopgap until they’re implemented in Go?</p>
<p>Please, please, please do not start a flame war. I know generics in Go is a hot topic and can blow up really quickly, but I still wanted to know the sub’s opinion on this.</p>
<hr/>**评论：**<br/><br/>TheMerovius: <pre><blockquote>
<p>That point sounds familiar to me with the generics in Go arguments.</p>
</blockquote>
<p>Why, though? Generics aren't <em>new</em>, I think "missing the boat" isn't really the issue or a claim to be made (right now, the more apt comparison - from a type-system perspective - wouldn't be generics, but rather dependent types or the like.</p>
<p>I would even argue, that if anything, the story should be the other way around here: Generics were well established when Go came to be, but it still is a good success so far without them. So, if anything, it seems to indicate that jumping on that boat wasn't really necessary for other languages out there.</p>
<blockquote>
<p>What are the qualities of Go that you like, that another language doesn’t have</p>
</blockquote>
<p>To me, this question is backwards. What makes me like Go is the qualities it does <em>not</em> have, that other languages have. Like overly complicated type-systems, syntactic sugar or "magic".</p>
<p>FWIW, everything it <em>does</em> have that other languages don't revolves not around the language itself, but the tooling. Go-get is amazing, gofmt is a must, fast compilation, good introspection tools for benchmarking and profiling…</p>
<p>So, the (to some) uncomfortable answer of why I use Go and not some other language is… Because it doesn't have generics and other type-system extras that make the language a pain to use.</p></pre>marnues: <pre><blockquote>
<p>What makes me like Go is the qualities it does not have</p>
</blockquote>
<p>This is why I've picked Go for my recent projects. I was doing a lot of Scala before Go, and I've grown tired of trying to figure out what esoterics would express what I want. I'm not as worried about declarative statements, I can still design my code this way, and structs are just as enjoyable as case classes over Java objects.</p></pre>[deleted]: <pre><p>Thanks for your thoughtful response!</p></pre>kd7nyq: <pre><p>I completely agree with this. I started using Go very early on (early 2012) because I found myself without an employer, and unlikely to find one. I needed to make money on my own, and, when you find yourself negotiating contracts, maintaining client relationships, managing your own infrastructure, and handling finances, coding needs to be the easiest thing you do.</p>
<p>Go was just what I needed. It was inexpensive to write and run (no paid IDEs required, and it ran on Linux). It was super simple, meaning I spent more time thinking about the problem than the language. It was fast, meaning I spent more time coding than waiting for compilation and tests.</p>
<p>Go really is the language the 'as simple as possible, but no simpler' language. My greatest fear is that some stupid demand from the "community" will cause the people with experience and knowledge behind the language to question themselves. Who on Earth really has more relevant experience than Rob Pike or Ken Thompson on the matter? How many people that are begging for generics have PhDs? Go's source is open and available; if someone wants to add generics, go for it. Otherwise, I see nothing wrong with letting the language masters do what they think is best.</p>
<p>The generics issue is a matter of backseat driving. The driver is experienced, knowledgeable, insured, and owns the darn car.</p></pre>smartsam69: <pre><p>Why is he being downvoted for this?</p></pre>shovelpost: <pre><p>Circle jerkers discovered the thread.</p></pre>postman_: <pre><p>i hope you will become obsolete with the coming of generics</p></pre>wdouglass: <pre><p>you mean like lisp has had for many years? The ones that C++ watered down to make templates? I don't think generics are making or breaking any language any time soon.</p></pre>Morgahl: <pre><p>The single strongest argument I have seen for generics in Go is for data structure libraries. However they can be done without generics at the cost of additional time complexity due to 'copy paste' of functionality across implementations. That said, I have found that having that separation of functionality offers type specific optimization opportunities that I find are more then worth keeping independent implementations of.</p></pre>014a: <pre><p>I have a hard time coming up with features that other languages have that I truly miss in Go. Its true that there are times I'll be writing some code and think "this would be a good use-case for a generic", but 9 times out of 10 the lack of a generic isn't forcing me to write more code, its more like the "OO Design" part of my brain is just seeing use-cases for them that will never be used.</p>
<p>If I could add one thing, I'd probably add language-native map/reduce on arrays and slices, probably just as global functions like append. If we had generics we could write these ourselves, but I don't think I want generics in Go, so I'm happy tip-toeing toward generics without getting all the way there.</p></pre>inf-groupoid: <pre><p>You realize parametric polymorphism (allowing definitions to work uniformly on all types) is orthogonal to object-orientation (packaging data structures with the operations that act on them), right? (Ironically, Go <em>has</em> support for object-orientation.)</p></pre>arp242: <pre><blockquote>
<p>Python missed the boat on concurrent programming</p>
</blockquote>
<p>Except that it didn't; you can write concurrent or parallel code in Python just fine. Yes, the GIL <em>can</em> make that harder – or even impossible – in <em>some</em> cases, but for many cases it's not an issue.</p>
<p>Also the vast majority of programs written are simple single-threaded applications, and I don't expect anything to change there. The GIL speeds those up. So it's a (reasonable) trade-off to make.</p>
<p>Is Python the <em>best</em> language if you want to write heavily parallel code? No, clearly not. But no language is "the best" at everything. The idea that "every language MUST have feature X or it's outdated and sucks!" seems a bit daft to me.</p></pre>rom16384: <pre><p>Python is one of my favorite programming languages and I think the GIL is a feature. I also think that Python failed in terms of concurrency. Instead of having a single clear way of implementing concurrency "There should be one-- and preferably only one --obvious way to do it.", there are many, and IMO they are all lacking. gevent only works with some compatible libraries, concurrency based on threads won't work well due to the GIL, and multi-process based concurrency (managing worker processes and failures) isn't as easy as it should be.</p></pre>shovelpost: <pre><p>What's great about Go's concurrency model is that it is part of the language and not a library.</p></pre>myringotomy: <pre><p>I don't like go as a language. I think the syntax is weird, I think it's unnecessarily verbose, I think the error handling is atrocious, I think the type system is archaic.</p>
<p>I use go because it's got a good compiler, because it supports a lot of platforms, because the library is rich, because the runtime is fast and efficient.</p>
<p>I tell you what though. If the crystal team has the resources of the go team I'd drop go in a heartbeat. Crystal is everything go should be but is not and never will.</p></pre>carsncode: <pre><p>Took one look at Crystal, saw Ruby-based syntax, threw up in my mouth a little, closed the tab. I will never understand why some people are so fond of that particular mishmash of ideas from Perl and Visual Basic.</p></pre>kostix: <pre><p>Please take no offence (no really, I don't intend to inflict it)
but to me, you just seem to be too fixated on a particular feature,
and hence your judgement about programming languages is weridly biased.</p>
<p>To compare, if we move a bit into a more material world with that "the right tool for the job" statement, and consider, say, hammers, you sound like insisting on using any hammer <em>but</em> only if it plays a Britney Spears song while you're wielding it.</p>
<p>To get back to the realm of computer programming, when someone (again) asks for generics, the canned response is always "what <em>particular</em> task you intend to solve using them"?
And, really, this is not just playing smartasses.
The real reason is that people much too often have certain fixations on certain features or misfeatures of particular tools (sure, we all do have them).</p>
<p>To rephrase, you're stating the dire need for generics <em>up front</em> without even writing any code. So I'm reading this, while taking a break from the 100 ksloc Go codebase I'm working on here at my $dayjob. It does not use generics, and I can't remember we needed them. Except from maybe that recent port of some component done by a Java guy.</p>
<p>To reiterate, I'm not telling the generics are not needed;
instead, I'm trying to convey that they quite often appear to be not that essential in real code.</p>
<p>So, it's weird to state "no generics, no Go". That's a distorted view of reality IMO.</p>
<p>For a more extreme case, consider <a href="https://groups.google.com/d/topic/golang-nuts/rzLzp_Z74ik/discussion" rel="nofollow">this epic thread — "No Allman style, no Go"</a> where a person argues
that if Go does not support the so-called "Allman" style of brace placement, it's impossible to use the language.
And everyone goes like "Uh... But we're using it to write production code..." ;-)</p></pre>[deleted]: <pre><p>Maybe I’m not understanding what you wrote 100%, but the articles I posted are on the topics of generics, so that’s why this post is about generics and why it seems like I’m fixated on generics. It seems like you think I’m arguing for against generics in Go, is that right? If so, then that’s not what my intention is. I want to know why individuals in the community are arguing either for or against generics in Go and if they consider alternate languages with generics because they’re not supported in Go, without providing my own opinions about the topic. Dave Cheney had arguments for both sides, so I reference them both in an effort to show the pros and cons he’s come up with. I’m also not clear on the hammer analogy you provided, can you clarify?</p>
<p>Also, I appreciate you taking the time to post your answer and I take no offense to anything you’ve posted.</p></pre>tetroxid: <pre><blockquote>
<p>100 ksloc</p>
<p>does not use generics</p>
</blockquote>
<p>I wonder if there is any connection between the two.</p></pre>kostix: <pre><p>No, there is no such connection.</p>
<p>As someone else pointed out in this thread, generics are useful when writing <em>generic</em> container/algorythm libraries or code like this; we're not writing a such a library.</p>
<p>At some point we considered code generation for implementing one particular feature but got away without it (and without code duplication, too).</p></pre>tetroxid: <pre><blockquote>
<p>At some point we considered code generation for implementing one particular feature but got away without it (and without code duplication, too).</p>
</blockquote>
<p>Does that piece of code have compile-time type safety?</p></pre>kostix: <pre><p>Yes.</p>
<p>But that's not "it always can be done this way" sort of thing.
Just in this particular case it was possible to engeeneer a solution
which is type safe w/o using generics and code generation.</p>
<p>One may say that lack of generics forced us to actually think,
and that is true to some degree, but certainly it should not be
taken as some sort of an apology for the lack of generics.
(Though I, for one, am ambivalent about their presence or lack thereof.)</p></pre>tetroxid: <pre><p>Can I see it? I'm curious how you solved it</p></pre>kostix: <pre><p>Sorry, not completely (I'm under an NDA for obvious reasons) but the general idea is as follows: we wanted to implement pooling of "compressors" (and decompressors) provided by the excellent <code>github.com/klauspost/compress</code> library.
The point was in that initalizing a freshly created compressor instance which happens lazily on its first use for compressing takes noticeable time, so there's tangible gain in pooling the created instances—taking them off the pool and resetting when another goroutine needs to compress the payload of the HTTP response it's generating or decompress that of the HTTP request it handles.</p>
<p>Since there's several standard compression methods available for HTTP, and <code>github.com/klauspost/compress</code> supports <code>deflate</code>, <code>zlib</code> and <code>gzip</code> (actually, HTTP's "deflate" is <code>zlib</code> here),
the first draft idea was to use code generation to produce several implementations of "pooled" compressors/decompressors from a single "template" — parameterized by concrete types provided by the different packages of <code>github.com/klauspost/compress</code> implementing the particular formats/algos.</p>
<p>The actual solution was to get away with a "generic" type
which looks like this</p>
<pre><code>type Compressor struct {
Format string
readerPool sync.Pool
writerPools writerPools
makeReader func(r io.Reader) (io.ReadCloser, error)
makeWriter func(w io.Writer, level int) (compWriter, error)
resetReader func(rc io.ReadCloser, r io.Reader) error
}
</code></pre>
<p>and have several variables of it exported from our utility package.
The relevant fields of each of these variables —
<code>makeReader</code>, <code>makeWriter</code> and <code>resetReader</code>, —
when created, are set to concrete implemenations calling out to
particular packages of <code>github.com/klauspost/compress</code>.
Each function is pretty thin (3-5 lines, including error handling).</p>
<p>The resulting utility package exports shared variables
implementing particular compressors—such as <code>Gzip</code>, <code>Zlib</code> etc.</p>
<p>(A <code>Compressor</code> uses several "writer pools" because each low-level compressor instance is initialized differently based on the compression level, so there's a lazily created pool for each compression level possibly used; the decompressors (readers) are all initialized the same way, so no such requirement exists.)</p>
<p>Not sure this explanation is what you expected
but that's all I have. ;-)</p>
<p>(BTW it's really interesting why previous post got 7 downvotes;
I fail to fathom any reason for them.)</p></pre>tetroxid: <pre><p>Ok, interesting solution. Thank you for taking the time to type this out and to explain it to me.</p>
<p>But this is not generics. You have different implementations for the same thing, which is interfaces. </p></pre>kostix: <pre><p>Well, the point I tried to get across is that
at first the idea which was getting kicked around
went like «well, we could have
<code>type PooledCompressor<class Encoder, class Decoder></code>»
which then naturally progressed into something like
«we could have codegen to have that»,
and IIRC the person who led the implementation of that
part back then squinted seriously at <code>github.com/cheekybits/genny</code>.</p>
<p>Then we came to that idea of having a single common type,
instances of which are indeed parameterized by concrete
implementations of three interfaces.</p>
<p>Sure, "this is not generics", but there's no generics in Go,
and I did not claim we somehow had them; quite the opposite. ;-)</p></pre>shovelpost: <pre><blockquote>
<p>BTW it's really interesting why previous post got 7 downvotes; I fail to fathom any reason for them.</p>
</blockquote>
<p>Your comment was discovered and mass downvoted by the circle jerkers:
<a href="https://www.reddit.com/r/programmingcirclejerk/comments/7m9ezz/one_may_say_that_lack_of_generics_forced_us_to/" rel="nofollow">https://www.reddit.com/r/programmingcirclejerk/comments/7m9ezz/one_may_say_that_lack_of_generics_forced_us_to/</a></p></pre>kostix: <pre><p>Thank you.</p></pre>: <pre><p>[removed]</p></pre>: <pre><p>[removed]</p></pre>
