Channels Are Not Enough
gist.github.com
gist.github.com
What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them.
I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem with CoffeeScript (conflation of declaration and assignment + scope rules) and the authors' refusal to admit that there is a problem also made me dismiss it entirely.
Every language/platform has problems. But not every language is in denial of them. We should all avoid those that refuse to acknowledge their problems - because that points to a much deeper, much more serious problem - a problem that cannot be eradicated with technical means.
Go does have generics for map but you can't create your own. I think they will add user generics at some point, but it may be a long while before that happens.
The Go community freely acknowledges that generics are a nice feature, and that lacking them is a pain point of Go sometimes. Although many Go developers will tell you that sometimes turns out to be not that often in reality, which has also been my experience.
Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.html
The bottom line is it's not a feature that comes for free, and if most of the time you don't really need it, maybe the costs aren't worth it. That's a bold statement for a programming language these days, since generics is a central feature of every popular, modern, statically typed language. Whether they are right or wrong I won't attempt to say. The language may well get generics one day, but it's early days still and the team is rightly focusing on more important features for the moment.
In my opinion, depriving a "normal" language user of generics is like depriving a Lisp user of macros. Whatever it is, its definitely not just "bold".
> I never thought people will actually come up and defend code duplication.
Indeed. Some of the responses by some Go fans really leave me surprised to say the least.
At least those communities embrace modern computing abstractions and code distribution practices.
Like PostgreSQL and OpenBSD, I've been permanently turned off Rust because I never want to be left at the mercy of a community that invests so much time in harassing and insulting others.
After all, when compared with the first Oberon version, Go only needs a few more primitives in runtime and unsafe, Kernel and SYSTEM in Oberon respectively.
This is what attracted me to the language in first place.
who is harassing or insulting anyone in the Postgres world?!?!
I basically stopped using (public) IRC somewhere around 2000. I have little idea what goes on in PostgreSQL's IRC channel(s). I expect it's toxic, but I'd expect that for any project's IRC presence. Public IRC is an inherently toxic medium.
Source code duplication is a risk of spending an hour, or maybe a day, of developer's time to detect the duplication, change it in concert in several places, with an occasional need of detecting and fixing a subtle discrepancy between the copies.
RAM is $0.015 per megabyte. Developer time is $50 per hour.
> I never thought people will actually come up and defend
> code duplication.
Overapplication of DRY as axiomatic has led to much pain and suffering.
Sometimes ugliness is a sign that something is designed incorrectly, especially if the language aids in making that more visually evident.
> (although not as ugly as converting your ints to float64 and using the stdlib min/max.)
Not to mention incorrect.
> it's ugly, but programming is not art, it's engineering
Not mutually exclusive. A good language would make incorrect or inefficient code "ugly" or "uglier" than correct code.
> and Go is a language for engineers.
So are languages with generics like C++, Java, Rust, Haskell, etc.
I'm sorry, I quite enjoy many aspects of Go - but the argument that committing one of the cardinal sins of programming is okay because your editor makes it easy is worse than the actual language shortcoming itself.
Sorry, I meant to say that the language's shortcomings, even if temporary, start to attract a wrong attitude, which is sad (and you, golang team, should feel sad).
Edit That being said, go is not for all projects. Some projects need a lot of generics. Don't use go for that.
If you write reusable, future-facing code, generic types without the erasure of interface upcasting is required. There are no two ways around it.
You're entitled to your opinions, but this is a patently false statement. There is plenty of C code currently running on my machine that was written decades ago and is still actively maintained.
> And this worse-is-better attitude of the Go community gives me a dim view of its future
The Go community actively embraces Worse-Is-Better. If your opinions are well formed enough that you know you want nothing to do with it, then what is your point exactly? Yeah, you hate Go because you hate Worst-Is-Better. So what?
You're right. Sorry. You can do it by enacting a fair approximation of stapling your eyelids to your hairline. I apologize for not being exhaustive.
> The Go community actively embraces Worse-Is-Better. If your opinions are well formed enough that you know you want nothing to do with it, then what is your point exactly?
That I've had more than one long night dealing with an inherited Go application and it sucks and its developers should feel bad.
(OK, the last is mostly facetious. If they can't be bothered to use modern tooling, though, they should be tasked with maintaining their own crap...)
It's a language meant for sys admins (which explains why it is popular with users of other languages usually used for sys admin jobs).
If your job is glueing a few existing services together, you won't miss Generics much.
Go is a language for people who write servers. It is really really good for those uses. Look at Docker, etcd, Kubernetes, Juju, Cloudflare, Soundcloud ...
And probably a ton that are internal to a company and not really exposed as a user-facing "Go Application™" (like the stuff behind google's downloads service, some of youtube's metadata processes, etc etc).
I think the fact that early on in Go's life someone called it a "systems language" really confused a lot of people. It's not a systems language. It's just a language. The channels, goroutines, and standard library happen to be really useful when writing networked servers.
It's even possible the software you were tasked with writing/maintaining was a bad fit for Go. I tried to mention that in my previous response. Such things certainly exist, and most Go enthusiasts will be more than willing to admit it.
However, saying you can't write reusable, future-facing code without generics is preposterous. To refute you, all I have to do is point you at the Go standard library. A huge body of code whose purpose is purely reuse, and not a generic to be found.
Or perhaps we could look at the thousands of reusable go packages found on godoc.org.
You don't like Go. That's a perfectly acceptable stance to take. But I don't think you've really given it a fair shake, either.
First of all that post was written by Russ Cox.
Second, it already has been discussed multiple times that it only focus on C++, C#, Java approaches while cleverly forgetting generics implementations exist in multiple forms since CLU (1974) introduced them.
But Go advocates take that page as dogma and toss it around every time a generics discussion comes up.
What evidence did you see to make this conclusion? I can only find from their FAQ[0]:
"Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
This remains an open issue."
Specifically, the claim that "maps and slices" can replace the ability to write abstractions such as futures, promises, observables as well as generic function such as map, reduce etc comes off as either naive or disingenuous
Furthermore, the "cost" of these features seems overstated to me. A lot of languages and runtimes already implement generics without significant compile-time or run-time overhead - why is it that hard for Go to do that?
"Go was designed to address the problems faced in software development at Google, which led to a language that is not a breakthrough research language but is nonetheless an excellent tool for engineering large software projects"[0]
They go on to list some concrete points on the type of problems they are trying to solve:
- slow builds
- uncontrolled dependencies
- each programmer using a different subset of the language
- poor program understanding (code hard to read, poorly documented, and so on)
- duplication of effort
- cost of updates
- version skew
- difficulty of writing automatic tools
- cross-language builds
I might not agree with the way they value generics but to me, it does seem reasonable given their design vision and goals.
And I'm not buying the poor programmer understanding argument. Generics aren't that complex, they're just parameterized types. The fact that basic language libraries such as maps and slices cannot be implemented without them speak volumes about how fundamental they are when building abstractions.
My point is that most of the backpressure against generics seems to stem from perceived added complexity to the compiler and type system, and thats all. But I'm not convinced thats a valid argument. Truth be told, I'm not a language implementer. But I know that fast compilers and runtimes that implement generics exist, so I don't find the whole discussion believable.
Are you arguing that an implementation of generics in a programming language is free? (Whether it be performance or implementation complexity.) Because if not, then you admit there are trade offs. If there are trade offs, then it is conceivable that some circumstances (including programmer tastes) may lead to a valuation that is different from yours.
"Performance" of the compiler is a critical goal of the Go project. Could you point out for me an industrial strength compiler that supports a type system of your liking that can match the compilation speed of the Go compiler? (I can't think of one.) Because if not, then I'll have to invoke this: talk is cheap, show me the code.
I am.
Performance: if you replace all generics with interface{}, you get performance that is at better or equal to current Go code.
Implementation complexity: You could add some constraints to generics, for example only interface types can be used as generic parameters, and all uses of variables/methods/functions with generic types need to have generic parameters given. In that case, there's no complexity for code that doesn't use generics. Also, generics could actually be implemented as a preprocessor that would simply insert appropriate casts from/to interface{} at calls to generic methods. Since all variables/functions in Go are declared and have known types, you could of course go further and eliminate most generic parameter annotations.
That is incorrect. Using `interface{}` incurs a significant performance penalty at runtime because you end up boxing everything. For example, you cannot cast a `[]interface{}` to an arbitrary `[]A`.
In other words, no, `interface{}` is not `void*`, sorry. If it was, Go would not be memory safe. (See golang.org for their definition of memory safety. It is strictly superior to a language like C, but e.g., less than a language like Rust.)
AFAIK it's not possible to write generic Go code without `interface {}` (or, alternatively, duplicating the code for each type).
`interface{}` is very rarely used for writing "generic" code precisely because of its lack of type safety and performance implications. If you came up with a way to make it type safe without addressing performance, you've just implemented a generics scheme that will cause programs to be slower than they would be without generics (because people would start using them!).
In other words, the only "cost" of generics, thus, is the social cost (there is no purely technical cost). Here, it boils down to the philosophical/political freedom-vs-safety question, and I strongly incline towards freedom. Go does not. Go's position is, if not wrong, at least loosing, since programmers demonstrably are using work-arounds (`interface {}`) when they need generics.
I just got through telling you that this type of use is actively discouraged, so no, people aren't using it as often as you might think.
If you want generics, you've got to pay for it. The implementation you've suggested requires a runtime performance penalty to use generics. Therefore, you have not demonstrated that generics are free.
There are likely other issues that golang needs to solve that are much higher priority issues, and there are flexible, even scripted languages that can handle higher level logic problems and scale very well. I wouldn't really expect to have to use generics for most of the problems I would look to go as a first language for a given problem.
Of course all of the above said, I'm a node.js fan and really like what it has to offer. It just depends on your use cases. Go is a really clean language/platform with a lot in the box, that I do appreciate. I would be surprised if they didn't support generics for v2, if not before. But I can see why they would want to punt the issue while there are bigger problems and needs to address.
I can't decide if my biggest problem with that answer is that it suggests that the primary use case for generics is generic containers (when, really, the main benefit of generic containers is being able to implement generic algorithms on said containers, like pmap), or whether it's the suggestion that breaking type safety in a statically typed language is a feature.
interface{} is barely an improvement over void*. The need for it suggests an insufficiently powerful type system. Go should either have a type system powerful enough not to need an explicit convention to avoid it, or it should have been dynamically typed.
That's not the claim. The claim is that generics add complexity to the language and its ecosystem. That, I'd hope, should be an undisputed claim.
Go's lack of generics is a design tradeoff. The occasional piece of awkward code is worth the overall reduction of complexity at an environmental level.
The Go creators do not deny that generics would make things easier. In particular, concurrency is one area where some kind of parametric type system would be really helpful. But we, and many others, are finding Go to be a great tool for a wide variety of jobs. It has won developer mindshare specifically because of our focus on simplicity. It doesn't seem worth compromising that to reduce the occasional bit of repetitive code.
(Note that I am in disagreement - I do think generics should be added).
People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.
Well, I guess I'll keep not being a Go programmer :)
That's not my experience at all. Generics are generally not a source of pain. Do you have any specific examples of your claim?
"It is possible to compile a large Go program in a few seconds on a single computer."
[1] http://golang.org/doc/faq#What_is_the_purpose_of_the_project
you see, the problem with the complexity of a language isnt real. it is perfectly possible to avoid generics in c++ forever. but there will come a day when you think to yourself, was it really worth it to be this lazy? then you take a peek and (assuming you understand generics by then enough to use it a little) suddenly half of what you have writen so far is for the bin.
It is a good sell when the audience only knows about C++ compilation issues.
What kills compilation performance for larger C/C++ projects is include hell and managing build dependencies, which as you point out is mitigated in language with modules.
Not sure. If absorbing it would make the compiler much slower, much more complex, or the compiled code less deterministic, or corner cases in the compiler much more numerous, I think it may be reasonable to not go this path.
It looks like the go compiler in itself is a nice piece of engineering, like a F1 race car. And a bunch of guys say they want it with automatic gears. Proposing an automatic version would change too many things in the internals, and the result would be another kind of cars.
Why would that be the case for Generics?
I think nobody says "Go needs Generics, but the implementation needs to be horrible."
There is also a chance that it will slow down compilation and or runtime. Java, C++ and other code compiles slower. Is it because those languages are stupid and slow and made by idiots? Not necessarily, it is because they have more features. Many added later (with added complexity of keeping backwards compatibility). The fear I think, is if Go gains those new features, its compilation and/or execution speed or claims of simplicity will not hold any more.
Yes, the tradeoffs have been made. The language has been designed. It is very unlikely that Go 1.x will see generics.
Yes, any new language feature may slow down the compilers and/or runtime. Go values compilation and execution speed highly very highly. To include any new language feature we would assess whether it is worth the various costs; that much is obvious.
But there are technical reasons why C++ and Java could never compile as fast as Go, and they have nothing to do with generics. Go's dependency model is the main reason it can build fast.
And simplicity is a core tenet of the language design. To sacrifice that would be to admit defeat entirely. We could have just been using C++ all along.
Well that was my point it. Turning Go into something like Java or C++ will make it not Go any more.
> We didn't build Go in order to have arguments on a mailing list.
Not sure many popular languages were built for that. But arguments on mailing lists is what you get. Quite often the smarter people are, the better they are able to veil things like disappointments, personal dislikes, and others in technical arguments. I have seen it in private meetings and public discussion forums. The inertia of defending something vigorously and then having to back-pedals is unpleasant.
In practice it's pretty much a measure of the temperature of bear porridge that a given person currently finds just right.
Eiffel, Ada, D, Modula-3, Active Oberon, FreePascal, Delphi... enjoy fast native code compilers and do have generics.
The issue is that a programmer needs to understand how the generics model works and how it interacts with every other feature of the language. That makes the language more complicated, which (as you say) leaks into the higher levels.
Generics is just one of many features that Go could have, but does not because it makes the language bigger.
Of course, a codebase in it and of it self can be complex, regardless of language (and even if the language is well suited for the job), but I am only talking in the context of when features (or lack thereof) in a language increases the codebase complexity.
But a few more lines in the same function to do the same thing as a single line in another language, is not more complexity, that's just more lines. It's not like the lines now are somewhere obscure or in another function.
Agreed.
> Of course, a codebase in it and of it self can be complex, regardless of language (and even if the language is well suited for the job), but I am only talking in the context of when features (or lack thereof) in a language increases the codebase complexity.
Agreed.
> But a few more lines in the same function to do the same thing as a single line in another language, is not more complexity, that's just more lines. It's not like the lines now are somewhere obscure or in another function.
And here's where we begin to disagree.
I delete redundant comments in code, even if they're correct.
This is significantly more effort than leaving them alone: I have to recognize they're redundant, check VCS history to ensure I'm not missing something, create a changelist, request a code review for the changelist, wait for the reviewer to verify I indeed didn't missing something, submit the changelist, verify the changelist still builds (you never know when you'll hit a bizarre compiler bug, corrupted file, conflict resolution related typo), merge the changelist back to the mainline...
This is a significant amount of work! But I feel it's justified: they're increasing the complexity involved with reading the code. The more pointless redundant comments I'm reading, the less important things I can remember, and the more likely I am to skim over something important such as a bug.
This is not additional cyclomatic complexity in the codebase. Structurally, the complexity of the fundamental operations my program performs haven't changed - I haven't touched anything that should affect the final executable output in any meaningful form at all. But I'm still making it simpler* to read.
(* a synonym of simple to note: noncomplex!)
In non-comment code, the problem is much worse. More code means more opportunities for typos, more code which must be read to grok the actual execution of the code. If you thought bugs got missed when I was skimming past the comments, well let me tell you, it's way worse when I start skimming past the code! And this happens to everyone.
There are still a few people who don't mind writing all their programs in straight up assembly. Sure, it's a bit more code, but all the if and while conditionals from C aren't reducing the cyclomatic complexity of their programs either compared to structured programming with conditional jumps. They say there's more important things to worry about than pure line count - and they're entirely correct. They're writing codebases in assembly that I'd find much more readable than some of the codebases I've read in much much higher level languages.
But having addressed the more important stuff I'd still like to address the less important stuff. It eventually adds up, and I've seen it make me more productive. (This has encouraged me to try many different languages... so far not Go, I've yet to come up with a problem which makes it the right language for the job.)
I strongly dispute/oppose that claim.
1) Generics don't add any complexity to the rest of the language. If you don'y use generics, you're back to the "plain Go". Especially since generics doesn't mean just "ML-style polymorphism"; I'm pretty sure that many people would be happy with a very limited implementation of generics, e.g. only for reference/pointer types (or even only for interfaces), with all types/generic arguments declared, not inferred. In that case, implementing generics would only require a change of the type-checker of the language, or in the case of Go, not even that, which brings me to the second point:
2) Generics are already implemented in Go (the compiler/the language/the libraries), via map/arrays/slices, it's just not accessible to user code. I really can't see how anybody could make an honest claim that "Go is avoiding generics because of added compiler complexity", when that complexity is already there.
For what it's worth, I have had a similar experience.
One time I expressed a personal opinion on G+ about something I don't like about Go personally. A Go fan re-shared this in the Go community and it turned into a debate. https://plus.google.com/+RalphCorderoy/posts/ZfaM1a21tyW
People argued that my concern was theoretical and would not happen in practice.
Then, by chance, someone wrote a totally unrelated blog article about their actual experiences writing Go. The article was overall positive about Go, but among their list of dislikes from using it in practice was exactly the concern I had voiced.
I posted this to the thread and the response I got was: "When I read that, he didn't give an example of it coming up. Again, it seems purely hypothetical."
Apparently a person writing about their experiences who says "There are a few things about Go that I'm not super happy about, and that tend to bite me from time to time," and then talking about problem X, is not enough evidence that X actually happens.
I took from this experience that, at the very least, there is a strong bias against admitting problems.
https://github.com/clipperhouse/gen
I'm sorry you got the impression of that there is a strong bias against admitting problems. I haven't seen that bias at all myself. Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language.
The first link deals with automatically generating things like printers or comparison functions. Its orthogonal to type abstraction - for example, in Haskell you would use "deriving" or TemplateHaskell macros to do the same thing. This kind of code generation is useful for creating monomorphic functions that depend on the structure of a type (for example, a comparison function for that type) but it won't help you latter create polymorphic functions that work on any type (for example, a sorting function that receives that comparison function as a parameter).
The second link suffers from a similar problem. The only types that can be used generically are the ones defined together with a "//gen" comment and you also can't define your own generic functions (for example, a SumOfDistinct function that composes Sum and Distinct)
You are giving me the impression that people are trying to solve Go's generics problem with tooling when its actually a language design and type system problem.
Go community lives in 1993, back when C++ compilers shipped with code generation tools (mostly macro based) and templates only existed in CFront.
Are these links in relation to generics? Generics weren't the issue I had been posting about.
> Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language.
For what it's worth, if the people responding to me had said "yes, what you say is a potential downside of our approach, but we think that the advantages of our approach outweigh the disadvantages," that would have been fine. There would have been no need to debate anything further.
The reason the argument went on is because the Go advocates were dismissing the possibility that my concern had any validity whatsoever.
Everything in there listed as impractical in Go is possible in D without external tool, with just regular meta-programming:
- generating parsers from grammar https://github.com/PhilippeSigaud/Pegged
- embedding files as array of bytes:
ubyte[] = import("file.jpeg");
- generating tables at compile-time with CTFE
Instead of copying what works the Go leaders pretend it doesn't work.
Every language decision has pluses and minuses. I think most Go programmers feel that this problem is fairly hypothetical because it doesn't seem to come up for most people in real code. But, you're right, it's possible for it to come up. Every language decision has minuses, including this one.
But the pluses outweigh the minuses, so this is not going to change. Sorry.
Why keep posting it? As you have seen in this thread, many people avoid Go not because it's not a very good language, but because of the way Go people deal with language problems and can't admit issues.
Being dishonest will just alienate even more people.
The only point that post is making is that generics have a cost. Are you saying that is false?
> Being dishonest will just alienate even more people.
What are you hoping to achieve by insulting a large group of people? If your goal is to alienate them, then surely that is an effective tactic.
Did you actually read the article?
> The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?
Wrong.
Additionally, not having Generics has a cost, too. People might disagree which cost is higher (Generics vs. no Generics), but acting as if there was a lower cost solution of "no Generics now, but retroactively add them later" hiding somewhere is just incredibly disingenuous and delusional.
Given your cost argument, there is absolutely no position under which "we don't have plan, but might consider it in the future" would give a favorable outcome. Why not just be honest and tell your users that Generics will never arrive?
> What are you hoping to achieve by insulting a large group of people? If your goal is to alienate them, then surely that is an effective tactic.
Oooooh. Burntsushi pulling his "whine whine you weren't nice to me first!", how unexpected ... not. It's a fascinating pattern which happens as soon as you run out of on-topic arguments.
Sure there are, including the following possibilities: 1) There are situations in which generics are a net benefit and situations in which generics are a net cost, and currently Go's target are is the latter, but because of drift in what people what in given domains, it evolves toward the former, 2) New advances in understanding of language design and implementation change the tradeoffs of generics such that they are a net benefit in places where currently they are a net cost, 3) The reason generics are a net cost in the current situation of Go isn't fundamental as a featre, but a matter of opportunity cost given other things that were and are being implemented in Go that implementing generics would tradeoff. A future implementation that doesn't disrupt non-generic-using code once other higher-priority features are implemented wouldn't be a net cost. But that's farther out than Go's current roadmap.
> Why not just be honest and tell your users that Generics will never arrive?
Because its not honest to state a decision that hasn't actually been made.
"New advances" as in "the last 50 years of progress in language design which we have conveniently ignored"?
There are languages from the 60ies which are better than Go (but lacked Go's distinguishing feature, the Google brand).
> Because its not honest to state a decision that hasn't actually been made.
Given the constraints they have already made a decision.
No, new advances as in, "new advances". The universe changes, and the context in which the decision not to prioritize generics now was made is not fixed.
> There are languages from the 60ies which are better than Go
"Better" is both subjective and use dependent, and, in any case, that claim is irrelevant to the point under discussion, which is whether or not it is logically possible for the cost tradeoffs to disfavor generics in Go now but favor them in the future.
> Given the constraints they have already made a decision.
Given the current constraints they have already made a decision not to develop generics now.
They have not made the decision you claim that they would be "honest" to announce, to wit, that Go will never have generics.
It may be that it won't, but that's a not a decision that they have made (nor is it a decision that it would likely ever make sense to make. Why ever say "never"?)
The article says it: "do you want slow programmers, slow compilers and bloated binaries, or slow execution times." The first "slow programmers" cost is addressing the absence of generics in the language. Thus, it admits a cost.
> but acting as if there was a lower cost solution of "no Generics now, but retroactively add them later" hiding somewhere is just incredibly disingenuous and delusional.
... Nobody is acting that way. I've said nothing about the relative weight of any cost, nor have I claimed that a lack of generics has no cost. I mean, the link I gave you admits that a lack of generics has a cost right there. You even quoted the relevant portion.
> Given your cost argument, there is absolutely no position under which "we don't have plan, but might consider it in the future" would give a favorable outcome. Why not just be honest and tell your users that Generics will never arrive?
I don't understand what point you're trying to make. Are you saying that the Go language maintainers are purposefully lying to everyone? Do you have evidence of this claim?
> It's a fascinating pattern which happens as soon as you run out of on-topic arguments.
And insulting people doesn't fit that pattern? Yikes.
That's an issue you simply cannot fix in CS, you need a new language/fork (not having var/let is at the heart of the language's syntax). I wouldn't compare it with Go's lack of generics.
Why? It feels like forking Go would be the fastest way to get Generics.
But on the other hand, the people who are able to pull that off usually just stay away from Go in the first place.
Also, type casts don't cause runtime panics. You can use type-based switch/case or check the "ok" return value from the cast to see if it worked.
There is a reason why Java completely abandoned that position.
From the Go FAQ:
Why does Go not have generic types?
Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
"...we understand some programmers do... ...we continue to think about it... ...This remains an open issue."
> Go doesn't let you build abstractions - it offers what
> it does, and if its not enough - tough luck.
Of course: turing tarpit, greenspunning, yadda yadda yadda, but his point remains: Certain abstractions with a low cost/benefit factor are just not expressible in "idiomatic" Go.
to be honest, if i need a stack, i usually implement it for the type
in question, or inline, as it's only a very small number of lines:
type stack []T
func (s *stack) push(t T) {
*s = append(*s, t)
}
func (s *stack) pop() T {
n := len(*s)
t := (*s)[n-1]
*s = (*s)[:n-1]
return t
}
Also, it could be something much more complicated than a stack, like the data structures in the STL... but that point has already been made elsewhere.
Remember that one of Go's primary stated goals is "speed of compilation"[1]. Simplicity and ease of learning are paramount, and it's easier to learn a language where any chunk of code basically follows the same rules as any other.
The idea is that you create a library which communicates using channel interface. Great. Now you need to add `i.(myType)` wherever. So, create a function that accepts an interface, switches on type (switch i.(type)) and returns a value with your concrete type.
It's a 6-liner solution to most of this rant about channels.
In go, where interfaces are implemented by default and `interface{}` covers everything, you also don't need to. It's just a little bit (~6 lines) of code to add to guarantee it while they figure out a nice way to add generics.
With Java I can hot reload classes to get instant compilation times in 99% of cases. With languages that use a REPL I don't even need to compile at all until almost all my code is written.
Yes, that does seem to be the distinctive thing about Go. It's almost like someone read Paul Graham's "blub" essay[1] and thought, "what would it mean to take seriously the idea that blub is the best language?"
Everyone knows that building abstractions has a cost - the cost of building the abstractions themselves, the cost of figuring out the particular abstractions employed in a given project, and the cost of comprehending a language flexible enough to support these abstractions. The hope is that the cost of abstraction is an investment: the time you put in will be rewarded in faster development when you put the abstractions to use. But at some point increased abstraction is going to give diminishing returns.
Now, most programs written today don't involve that much more abstraction than would have been possible with programs written in ALGOL; that is, we haven't seen a huge widespread increase in the power of abstraction used by most programmers in about 50 years. People like Alan Kay and Brett Victor[2] decry this stagnation, and maybe they're right to. But maybe the current low level of abstraction is so durable because it's a sweet spot between the benefits you get from abstraction and the costs involved in coming to grips with that abstraction.
Most people, particularly most people who develop programming languages, assume that we're nowhere near the point of diminishing returns for increasing abstraction. Go seems like an experiment to test the possibility that the maximum efficiency occurs at a much lower level of abstraction than we usually think. It will be interesting to see whether (or in what domains) that hypothesis turns out to be true.
[1] http://www.paulgraham.com/avg.html [2] http://worrydream.com/dbx/
If you look at code from the newer fancy languages people do use these fancy features.
Perhaps Go implementers could use similar approach?
Keep in mind that, were I to write this again today from scratch, there are a number of things I would do differently (since I started it as a relative beginner expanded on it as my familiarity with Go developed, it's grown to be a bit over-engineered in places). But I still think it's a worthwhile example in this discussion.
For concurrency, I wouldn't say that what OP is trying to do is going to be easy in any language, because OAuth in general kind of sucks[1] the Twitter API itself has a number of quirks that make it cumbersome in general, irrespective of language[2]. That said, Go was by far the easiest to work with here, because channels allowed me to abstract the pagination and the rate-limiting in a way that it would be invisible to all callers, but "magically" handled behind the scenes.
Without going into too much detail, I can see that the way OP has designed his code looks a bit cumbersome. That said, while it's a reasonable way of approaching it, I don't think it's actually the best approach in Go given the language's idioms.
One other thing I want to draw attention to is the use of the general-purpose function for issuing a GET request to Twitter, and how that is shared among the various functions that use it to return values of varying, but known, types.
I don't want to use the word "generic" here because people expect a certain thing when they hear that word, but I will say that this function is (A) general-purpose, and (B) type-safe - it involves no type assertions, and the functions all return concrete types instead if interface{}.
[0] https://github.com/ChimeraCoder/anaconda/
[1] Don't get me started on this
[2] I've written client libraries for Twitter in a few different languages, so I actually have a reasonable point of reference on this - at one point, it was my personal "hello world" for testing out a new language.
This looks like a good example of interface{} used correctly - the consumer of the apiGet function passes in their strongly typed object, which then is handed in to json.Decode. No type safety is lost from the perspective of the consumer, while the json.Decode can operate on any struct type.
Sure this addresses a different issue, but for all the complaints about interface{} I think this is a good use-case.
Also, if it can't be solved elegantly, perhaps adding merge() and a few other important functions to the language would be good enough? After all, Go already has the magic append() function for slices and we get quite a lot of use out of it.
1) Create a "generic" version of the function using reflection / typecasts 2) Create a specific version of the function for your use-case
I don't have a ton of experience using channels. My code tends to be very imperative and I add the channel layer at the main application level rather than the library level.
So from his example:
> func merge[T](cs ...<-chan T) <-chan T
You can create a function:
func merge(cs ...interface{}) interface{}
merged := merge(c1, c2, c3).(<-chan int)
But even languages with generics often have similar issues. For example you can't write a generic min/max in C# either.
min :: Ord a => [a] -> Maybe a
min = foldl' go Nothing where
go Nothing a = Just a
go a0@(Just m) a
| a < m = Just a
| otherwise = a0
module Min (M : Comparable.S) : sig
val min : M.t list -> M.t option
end = struct
open M
let go a0 a = match a0 with
None -> Some(a)
| Some(m) -> if a < m then Some(a) else a0
let min l = List.fold_left go None l
end
The only use case that I have encountered that is essentially impossible in Go is the "generic data structure". Mind you, that's a bit of a big deal, even if it covered over by "generic" arrays and maps (which, further, does cover over a lot of the cases), but it is also the only case where it is actually a problem. Despite the fact Go is not functional, like, at all, I still find myself using my functional training in minimizing the surface area of an "object" as much as possible incredibly useful when programming in Go. I think if I were only an OO programmer trying to come over to Go I'd have a much harder time of it.
Most of the rest of the time you can solve your problem by asking what the code is really trying to do, pull that up into an interface, and carry on. A substantial portion of the rest of the use case can be covered by providing wrapper objects that compose in another object, probably using an interface as the composition point.
I think in practice, about 80% of the problems that people trying to jam generics into Go are encountering are because they are trying to program C++, Java, or C# in Go. Despite their substantial superficial similarities, Go is not any of them, and idiomatic answers differ substantially. Let me rhetorically underline that... Go really looks like a Java or C# clone if you just read down the bullet points, but there are enough important differences that it's a substantially different experience to program in it. Trying to program Go as C# is only slightly less frustrating than trying to port FP idioms into Go (which is a complete waste of time). The remaining 20% are real problems that Go hasn't got a good answer for beyond duplicating code.
Now. All that said, despite the fact that people not used to idiomatic Go are significantly overstating the problem that is the lack of generics, it is a problem and were I in charge, I'd be trying to work something out on this front. (I actually have a proposal I've probably put about 4 or 5 hours of thought into. In defense of the Go developers, this is a nontrivial problem when you stop just waving the word "generic" around and start trying to seriously create an implementable suggestion, accounting for all the use cases, grammar interactions, semantics, etc.) My best argument is that for a language as mature as Go, this is embarrassing: http://golang.org/pkg/container/ Those are the "generic" containers in the standard library that ship with the language.... all three of them as of this writing, plus array and map. At this point that ought to be significantly richer.
(So, that ought to just about piss everybody off...)
Oh, I ought to add for context that I'm actually pretty fluent in Haskell, and my primary work programming language up to this point have been dynamic languages (Perl, Python, etc). So it's not like I'm not comfortable with generics or incapable of understanding how to use them or anything. If anything, I dare say my openness to other answers and then finding ways to express them in Go may be part of why this doesn't bother me too much. There are other options, most of the time, and they are not generally "compromises", either... they are often perfectly sensible options, or even better options than are available in other languages on a bang/buck basis, such as the trade for making composition very easy and inheritance something fairly difficult.
Im mainly a clojure guy and we generally belive the CPS and FP go together very well. The new interduction of transducers makes this even clearer and it seams to me this is a feature that go should really think about.
Note that it does have closures, and makes heavy use of them. It just managed to pick up closures without picking up the rest of FP.
I think this generally fits into the spirit of Go being a really good language for working in a larger development environment, where you can't expect everyone to be expert FP programmers. And, honestly, an intermediate FP programmer is sorta dangerous to your source code, in much the same way an intermediate OO guy is. Go does a surprisingly good job of preventing the intermediate guy from messing up your code too much.
To expand on what I said about the principles of FP being helpful to me in Go even so, here's an example: http://www.jerf.org/iri/post/2923 In theory, there's nothing that prevents another OO language from doing that, but without the structural polymorphism that Go has with its interfaces it's so much less convenient that nobody does it, and, more importantly, nobody thinks that way.
In fact, in some sense I'd say Go is inspired by CSP, but to the extent that CSP involves the creation of these complicated networks of data flowing around, it doesn't really do that. On the other hand, I'm not convinced that's a very practical way to program... complicated networks just become one more source of "magic" in a program. Using CPS-esque tools to make it easy to connect components together is itself pretty powerful.
Some of these may be one-off generic functions like append() that could be added to the language without adding full-blown generics.
Futures I can be specific about, though. You simply don't use "futures" in Go. Futures (as the term is used by most languages) are a hack around missing concurrency constructs, and in Go, they aren't missing. Use channels instead. This covers rather a lot of patterns from Javascript and the weaker languages, actually... you don't port them, you simply don't use them. They aren't that appealing once you learn the native idioms, which are, generally, quite a bit better.
Putting a "future" library up on /r/golang is a pretty common occurrence... but they're so trivial they're worthless. It's harder to "use" a future than it is to just do thing the future library is doing.
For pipelines, you just "do" them... you don't set up some declarative pipeline, you just... program them. Sort of like how in the Python world they prefer the for loops to map statements? Same thing, really... if you want a pipeline, just hook things together manually. They may miss out on some abstraction, but, honestly, in most imperative languages I'm underwhelmed by the concept of really generic pipelines. Haskell's making some progress on that front and I've actually got an "in the wild" five-stager, but in the imperative world I'm not sure I've ever encountered in the wild some sort of 6-stage pipeline that was better written other ways.
If any major concurrency pattern is missing from Go, it's an explicitly asynchronous concurrency pattern. However, this can be fixed by library code: https://github.com/thejerf/reign
I think the essay is entirely correct: there are certain patterns that are difficult to write in Go. It's hard to write generic code that merges two channels into one. It's hard to write generic code that acts as a future.
But it's easy to write type-specific code to perform those operations. Most Go programs do not need to merge channels of many different types. So people simply write the code they need when they need it.
This is not to say that there is no use for generics. There is clearly a use for generics, and examples using channels are among the strongest use cases. I'm just trying to answer your question about what Go developers actually do.
Then perhaps Go is not the language for you. There are a lot of design decisions in Go that seem arbitrarily restrictive at first but are there, AFAICT, to (as much as is reasonable) force programmers to write code where what is happening is explicit and obvious without having to dive down into layers and layers of abstraction to find "the magic".
This is, IMO, a feature and not a bug, but YMMV.
I'm perfectly comfortable with the "theory of generics", but when generics first came on the scene for C++ back during the time period I used to program primarily in C and C++ they were very magical. Not on the run-time side where the eventual result of any sane compiler is easy to understand, but magical on the compile-time side where when using them it was nearly impossible to determine how much time they would add to the overall compilation and how complex and unreadable the error messages would be if you had a problem. When you make a single simple syntax error and the compiler presents you with an error that is 2 pages long that is the result of an implementation that is, IMO, very "magical".
Modern application programmers and even system programmers by your definition rely on a lot of "magic". Even the machine code these days is a layer or two removed from the actual metal with all the caching and microcode that reside on the CPU.
The first version of STL was actually done in Ada.
Don't mistake generics in programming languages with what C++ does.
Many thing common today where 'magic' once. So the line where something is magic is kind of meaningless.
Can't have a flexible iterator system because it might introduce complexity? Better just hide complexity in a next() function.
Can't have generics (except for the google-approved map, slice, chan...) because it might introduce complexity? Better just shift that complexity to unsafe use of interface{}.
And again, I think it is a feature and not a bug.
I didn't always think that way, I had a really rough start with Go because I was using it as if I were programming in a slightly different dialect of C++ which it isn't. When I write Go as if it is Go, I just don't see these "missing features" as problems at all.
But this debate has been going back and forth since Go was first made public, so anyone who has tried Go and dismissed it based on these lack of features is unlikely to be persuaded otherwise here and they should continue to use other languages until such a time as Go supports what they want (if ever). That's the beauty of having so many languages to choose from.
This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.
The others are conveniences to avoid subtle bugs and millions of developers writing the exact same code in every project.
I've mentioned this before, but my experience is that "expressive" is synonymous with "obfuscated". Go helps us in writing clear, maintainable code, not clever code.
Any abstraction can be "magic" to people who don't find it appealing or useful. Go includes some of those abstractions and excludes others, like any language. I don't know of any consistent criteria by which the abstractions Go provides are non-magic and the ones it eschews are magic.
We all understand how maps, slices, channels, and goroutines work. Their behavior is simple and mostly predictable. Developers working in C wrote these or analogous systems all the time. Over and over again, albeit commonly with subtle errors, particularly with regard to concurrency.
Slices and maps (or their close equivalents) are universal. They exist in a generic form in Go because everybody needs them, in pretty much every significant codebase. There aren't many other data structures for which that is true. Perhaps as importantly, many nontrivial codebases don't really need much in the way of other data structures.
Concurrency features are less universal, but are also the source of many critical bugs. One might reasonably say concurrency is inherently magic under my criteria, but unfortunately some form of it is unavoidable. Go's concurrency primitives at least make it easier to avoid common errors while minimizing additional magic.
My personal problem with adding generics directly to Go is not that they are magic, exactly (which I think you may have misinterpreted georgemcbay's comment to imply), but that they lead easily to magic. Go discourages overengineering, which is a common outcome of certain people applying generics (and there are a lot of those certain people, and I've had the misfortune to deal with their code throughout my career).
What I would like is for something like gen to become the de-facto standard (presumably in conjunction with the generate feature proposed for Go 1.4). I doubt if I'd use it much myself, but that outcome would at least placate demands for generics without making it all that easy to obfuscate what is actually going on in the Go code.
Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust.
There are things in all languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how close the core of Haskell is to just a simply typed lambda calculus. It's amazing at how Go can be so well specified in such a short document with near perfect orthogonality in the language.
Many of your comments in this thread read (to me) as if you're speaking from a position of authority on what the right design for a language is. I think your comments would be better received if you expressed your thoughts as opinions rather than as things you consider facts.
Thank you for the advice. I'll keep it in mind.
I quoted it in my comment. You said: "but [Go is] unsurprisingly frustrating for people used to more expressive languages." I'm used to more expressive languages too, but I don't find Go frustrating. Therefore, your statement is false.
You probably intended it to read like: "I am unsurprisingly frustrated with Go because I prefer more expressive languages."
Many of your other comments are similarly phrased. The read as if you are privy to some truth that people who like Go do not understand.
If it helps, substitute "it can be frustrating" for "it's frustrating".
Yes, OK, that is an entirely different claim altogether. Agreed.
(...and no, I don't think it's particularly wrong to assert that this is the case for other people too; there's plenty of evidence to support that people find the lack of generics in a fully featured language like go frustrating; and it's not surprising what so ever that this is the case)
So? My point was not to claim the opposite of the OP, it was to point out that the generalization is false.
> (...and no, I don't think it's particularly wrong to assert that this is the case for other people too; there's plenty of evidence to support that people find the lack of generics in a fully featured language like go frustrating; and it's not surprising what so ever that this is the case)
I guess, if your evidence consists of people on HN and reddit complaining about Go.
A majority of all people who use go? Certainly not.
...but consider that if you see lots of people complaining about something, its possibly not because they're all idiots, or pretentious self important HN posers (who certainly do exist).
The key issue being raised in this thread is that the golang community is dismissive of complaints, even when there are lots of them. and there are, quantitatively, lots of complaints.
That doesn't mean go is a bad language; it means its a popular language in the spot light, and its maintainers and community should probably make a bit of effort to be slightly more humble about that, rather than themselves becoming a pretentious 'there no problem here' self agreeing community.
I think thats a very valid concern, worth thinking about.
(and to be clear; I like go, but I dont visit golang-nuts anymore, because of the community there)
My only point was that just because you like languages like Haskell, that doesn't mean you can't have a fun time with Go. The reason why I said it was to push back against this notion that generics are clearly necessary in all modern languages. We should embrace alternative designs and consider them for the trade offs they make, not denigrate them as objectively incorrect.
If I had it my way, a good discussion of language design withholds judgment and outlines the trade offs. Once the trade offs are made clear, we can start to express opinions (or needs or judgments) based on which ones we want to make. This avoids the popular notion that there is some sort of minimal feature set that makes a language minimally viable.
FYI, these are not well formed thoughts. You could probably poke holes in them, but at the end of day: we should endeavor to balance trade offs in lieu of speaking from authority. (I'm not saying you are doing that, but certainly, others in this thread are.)
> The key issue being raised in this thread is that the golang community is dismissive of complaints, even when there are lots of them. and there are, quantitatively, lots of complaints.
What do you mean by "dismissive"? Most of the popular criticisms have been hashed out repeatedly on golang-nuts. Usually it comes down to the fact that a particular feature doesn't have a known implementation that fits into the design goals of the project.
The design goals are important because they say up front, "Here are the things we think are important and our project will be based on those things. If you think there are other things that are more important, then this project may not be for you."
That isn't dismissive IMO. It is an explicit statement of project scope.
> rather than themselves becoming a pretentious 'there no problem here' self agreeing community.
The problem is that they acknowledge the value of generics but don't know how to incorporate it without sacrificing other goals that are paramount to the project.
Just as you think Gophers blissfully cover the ears in wild ignorance, so to do they think that plenty of others aren't acknowledging trade offs. There is truth on both sides here. It is quite agreeable to say, "I have a really hard time programming without generics, so Go just isn't for me." It is quite another to say, "Go doesn't even have generics? Wow, they just ignored 3 decades worth of PL research."
> (and to be clear; I like go, but I dont visit golang-nuts anymore, because of the community there)
Yes, the community can be very thorny. But I can't blame them. They've been ruthlessly attacked since the start (generics, nulls, exceptions) for preferring a Worse Is Better approach to solving problems.
People de facto speak in the form of opinions, and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.
I don't follow. The rest of your comment posits an argument for why you think I was wrong. If you're going to accuse me of being condescending and hostile, then I think you at least owe me the courtesy of explaining why.
> People de facto speak in the form of opinions
I agree.
> and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.
I did not say we should do that.
> The parent was making a basic generalization; he didn't categorically claim that his statement applied to all people.
In a discussion of design trade offs, it is important to distinguish between technical fact and opinion. In language design in particular, it is too easy to conflate these things. This thread, for example, is full of it. (For and against Go, FWIW.)
To be explicit, then, I think your comment's tone was inappropriate for HN. You're taking a generalization and expressing displeasure in the fact that the generalization seems to have inadvertedly included you, and then blaming the commenter for having done so.
You have to be deliberately obtuse to assume that the parent's statement was intended as absolute fact. It doesn't matter if we're discussing technology, this is a conversation, not a textbook; it's a normal part of discourse to give the other party a little slack and not treat every utterance literally and in absolute terms.
Huh? I used "wrong" in the sense, "your argument is incorrect," not, "you shouldn't do that," precisely because your comment explained how you disagreed with me (not why you thought I was being a jerk). In that way, "wrong" and condescension/hostility are orthogonal concepts.
> You have to be deliberately obtuse to assume that the parent's statement was intended as absolute fact. It doesn't matter if we're discussing technology, this is a conversation, not a textbook; it's a normal part of discourse to give the other party a little slack and not treat every utterance literally and in absolute terms.
I stand by what I said. I don't know what textbooks have to do this. I'm not asking for rigorous debate here. I'm asking for a modicum of clarity in a type of conversation where clarity is important.
I agree that we should give each other a little slack. But I also think we should encourage clarity where we think it is necessary. I think it is necessary in this context.
> You have to be deliberately obtuse
But thanks for the insult all the same. Do you think that is appropriate for HN?
The "deliberately obtuse" bit was not directed at you specifically, but then if the shoe fits, etc.
Right. wink wink nudge nudge I didn't call you dim technically, but really, I did. Talk about hostility...
Welcome to the Go community.
At least by now, they updated their docs a little bit.
I still think the "How to Write Go Code" article, which most beginners will encounter, is absolutely misleading by its advocacy of 'go get' - I cannot envision a universe where 'go get' makes sense. You absolutely have to vendor your dependencies if you want any kind of stability with your project.
My explanation is that there is some kind of positive feedback loop involved:
(1) Go developers/creators think they are really really smart.
(2) Experienced developers see their flaws, stay away from Go, and never participate in the mailing list.
(3) Clueless developers join the mailing list and ask simple/stupid/beginner questions. Go developers can easily answer them, reinforcing their self-assessment in (1).
It's a scary feeling watching their echo chamber ...
I have several open source Go projects and I have been maintaining them for years by just using `go get`. I've never once had a stability problem because of it.
Of course, your point is absolutely correct. But I'm pointing out that `go get` can absolutely be useful in some universes. In fact, it's one of the things I love most of the Go toolchain.
So, umm, can we stop presupposing that everyone else's opinion and experience is just wrong?
> But the dangers of convenient facilities are notorious. For example, the repetitive commands with input guards may tempt the programmer to write them without making adequate plans for their termination; and if it turns out that the automatic termination is unsatisfactory, reprogramming for explicit termination will involve severe changes, affecting even the interfaces between the processes.
[0]: http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf
Just like Erlang has explicit processes and message sending primitives So it is pretty simple and concise at that level. In order to build large systems there is OTP (or e2) that embodies and abstracts away some common patterns/behaviours: gen_event, gen_server, gen_fsm, supervisors, logging, distribution between nodes etc.
I imagine over time go will acquire those kind of libraries (maybe it already has them?).
There is also an interesting duality between Erlang and Go. In one case there are explicit processes (identified by PIDs) + an anonymous (implicit) mailbox. Where go has anonymous goroutines but explicitly identifiably channels. It seems they are duals. You can simulate one with another. And you can build concurrency patterns on top of them.
I personally prefer Erlang's model to think about concurrency. There is an active entity -- a client request, a server, a socket handler, it has a an id/name, it can be monitored for liveliness, it can be halted, upgraded, killed, can send messages to it. Somehow to me that makes it easier to map to concurrent problem domains. Channels can ultimately do the same things but it is harder for me to design using goroutines.
Another thing is that assertions can only check primitive type. To check if a function pointer or object respects an interface you need to add an extra wrapper around it to check all its return values (and this is so annoying to do by hand that noone bothers to do it)
The closest I've gotten to that has been to create a single-member wrapper struct. Go provides a little bit of sugar for that, but it results in a decent amount of boilerplate and explicit wrapping/unwrapping.
type Foo struct {
pkg.Bar
}
func UseIt(b pkg.Bar) error {
return otherFunc(Foo{b})
}
Saying having less information about the data makes for easier coding is almost always not true.
You say that, but you probably don't actually do it. If it truly could "be anything" then you would not be able to do anything to it. This is the nature of polymorphism.
So instead, your algorithm constrains the polymorphism based on what you need. If you make use of the properties {small, bit-shiftable, sized, bounded, copy-safe} then you must prove (exactly and only) that whatever the generic variable gets instantiated to satisfies {small, bit-shiftable, sized, bounded, copy-safe}.
Indeed, this is part of how such a system prevents bugs---it forces you to express exactly how much information about the types involved is needed. You can thus reflect better on the kinds of contracts/laws things must uphold and are prevented from accidentally making use of a property of your concrete type which you do not demarcate.
In a truly expressive language you might write
foo : forall id n .
(Bits id, Size id = n, n <= 1024)
=> id -> {Copy id} id
Today, you can get promises very similar to the above by using a language like Cryptol[0].
Go was created for businesses, not developers. The holy grail of a corporate programming language is that all individual developer personality is restricted, such that _you cannot tell from reading code who wrote it_. This is all about long-term, large-scale maintainability for massive code bases at massive corporations.
Disclaimer: I work at Google, I do not represent Google, and this is just my opinion after spending time "on the inside".
> The ideal (from their perspective) is that there is only one way to do a particular thing
The lack of useful tools like generics (and others) means there is no single way to do a particular thing: things must be duplicated everywhere (or ugly workarounds to avoid doing so must be employed, like casting from Object or using interface{} or whatever). Surely the benefits of better tools outweigh their inconveniences, even in a corporate environment? This is not a nerdy programmer's whim, but a major software engineering principle of direct consequences for any business.
Taken to an absurd extreme, you can simply copy & paste code everywhere -- that's the simplest programming model there is, and even the most junior of programmers can handle it without having their learning skills taxed in any way. It just leads to maintenance hell, which is why it's frowned upon even in corporate environments.
http://www.reddit.com/r/programming/comments/1w2y01/rob_pike...
This Go client implementation https://github.com/pebbe/zmq4 by Peter Kleiweg also includes all the examples from the online zeromq guide which is great.
I know it's not a pure ago solution but the OP does mention that
'99% of time I don't really care if the response is delivered with a channel or a magical unicorn brought it on its horn.'
I don't know, maybe I'm missing the point of the article.
Hopefully, the Go team will see this as one more reason to add generics to their language, but until they do that, Go will remain a niche language with a severely crippled potential.
Well either a lot of developers there looking at Go code are crazy, whiny and in general unpleasant human beings that like to make others' lives difficult or ... maybe it is a problem worth discussing.
(Personally, I don't mind the ongoing discussions about generics in Go, I just wish they were less repetitive. It's very easy to say "add generics to Go!" It's a little bit harder to actually do it well.)
<quote> The size of an array is part of its type
If one declares
var arr10 : array [1..10] of integer;
arr20 : array [1..20] of integer;
The place where this affects Software Tools particularly, and I think programs in general, is that it makes it difficult indeed to create a library of routines for doing common, general-purpose operations like sorting. </quote>
Kernighan was one of the early C/Unix developers from Bell Labs. It is amusing to note that Go, whose authors come from the same background, getting criticized for something very similar.