Channels Are Not Enough

https://gist.github.com/kachayev/21e7fe149bc5ae0bd878

by kachayev • 12 years ago

235 221 12 years ago

gist.github.com

rdtsc4• 12 years ago

Yeah it seem channels are basic primitives. Kind of a like a class in OO programming.

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.

jorlow• 12 years ago

The problem (which the article touches on) is that you have to resort to interface{} to make things reusable since Go doesn't have generics. So you have to pick between using a library (which will handle edge cases better) or compile time type checking.

stcredzero2• 12 years ago

How about replacing certain compile time type checks with smoke tests and runtime assertions, or unit tests?

NateDad9• 12 years ago

You don't have to resort to an empty interface, in fact, mrust experiences go programmers cringe when they see anyone using empty interfaces. The fact of the matter that much code can reused without being "generic" and often your code never gets reused. YAGNI and all that.

djur8• 12 years ago

This is a really great read, and goes beyond just channels and concurrency. It seems to me that Go is designed to discourage developing higher-level abstractions. That was my sense using it in the past, and it's only gotten stronger over time.

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.

[1] http://golang.org/doc/faq#Why_doesnt_Go_have_feature_X

tonyhb2• 12 years ago

There's a way to make channels easy to use and abstract. Just make a typecast function. Details in a comment on the original post.

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.

djur8• 12 years ago

In a statically typed language, it shouldn't be necessary to break type safety to implement basic abstractions. The only thing interface{} provides over void* is safe typecasting.

threeseed• 12 years ago

Speed of compilation doesn't mean you need a simplistic language.

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.

voyou• 12 years ago

"Go is designed to discourage developing higher-level abstractions."

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/

nickik4• 12 years ago

I think what you are missing is that people do use abstraction if you offer it. Java or C# generics or even when C++ added templates. C++ templates where abused but it was done so often that is now standard.

If you look at code from the newer fancy languages people do use these fancy features.

nickik4• 12 years ago

As far as I know, correct me if I am wrong, D does have many of the features Go lacks, like generics, and also has very fast compile times.

polskibus• 12 years ago

Compilation can be parallelized quite well if the code is structured properly. I used Xoreax grid engine (incredibuild) on Windows some time ago with C++ and it was great at speeding up our builds. Shame C# isn't parallelized in the same way.

Perhaps Go implementers could use similar approach?

chimeracoder• 12 years ago

It's funny that OP uses Twitter as the case study at the end. I wrote what was then the first (and think still the only) Go Twitter client library that works with v1.1 of Twitter's API[0]. It implements automatic rate-limiting/throttling behind the scenes, and it returns values of concrete types (not interfaces) ready for immediate use.

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.

dkarapetyan4• 12 years ago

I'm curious to see this general purpose function of yours. You are also addressing a different point than the article. The main point is that patterns like parallel map are impossible to implement in Go in a type-safe manner. This is a valid complaint depending on what is meant by type-safe and at this point the arguments for/against Go usually devolve into name calling and matters of culture. If you could factor out all that general purpose functionality from your code base, e.g. the rate-limiting and other things, and turn it into a re-usable library then that would be an entirely different matter. Whether that would qualify according to the author's definition of type-safe is another matter.

jordwest• 12 years ago

It looks like this is the function: https://github.com/ChimeraCoder/anaconda/blob/master/twitter...

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.

wilsonfiifi• 12 years ago

Wouldn't a library like zeromq address the complications/shortcomings the OP highlights in his article, when working with Go channels on a regular basis? Using the 'inproc' for message transport with zeromq should give similar performance to pure go channels no?

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.

dkarapetyan4• 12 years ago

Sure, but at that point what is the point of using Go? You might as well use some other language like D if all the parallelism and message passing patterns are going to be handled by a library like zeromq.

spion7• 12 years ago

Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck.

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.

kyrra• 12 years ago

From what I've seen is that th Go team has no desire to change the core language syntax at this time. They are spending most of their time on toolchain and runtime improvements.

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.

eloff2• 12 years ago

Lack of generics != lack of abstractions.

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.

spion7• 12 years ago

That really depends on what you mean by "most of the time". After all, you only write a generics based library once, and you reuse it many times - therefore on the outside it appears that you don't really use generics all that much.

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".

ufo4• 12 years ago

Correct me if I'm wrong but doesn't the current state of affairs (using Interface{}) have all the downsides of Java's boxing but without any of the type safety?

kansface2• 12 years ago

The problem is that the code that needs generics is reusable abstractions in libraries. Thats probably 1-3% of code but it is also critically important and there is no convincing workaround.

jesstaa2• 12 years ago

That is Russ' blog post, not Rob's.

pjmlp13• 12 years ago

Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.html

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.

cjslep2• 12 years ago

[...] but because its authors and community is incapable of admitting problems when they see them.

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."

[0] http://golang.org/doc/faq#generics

spion7• 12 years ago

I believe that this is evidence enough that they're downplaying the importance of generics.

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?

djur8• 12 years ago

That answer has been there for a while. There hasn't really been any indication that the issue actually is open, other than a refusal to state outright "no generics in Go".

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.

enneff4• 12 years ago

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.

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.

spion7• 12 years ago

I think that the "complexity" cost of generics is overstated, really. Can you explain how generics make user code more complex?

kansface2• 12 years ago

The answer to the question "where should complexity go?" is always "as low as possible". Complexity at higher levels interacts with more code and begets more complexity. The lack of generics or macros is complexity that is forced on the end user which could be handled by the compiler (language devs).

tomp5• 12 years ago

The claim is that generics add complexity to the language and its ecosystem. That, I'd hope, should be an undisputed claim.

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.

haberman2• 12 years ago

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.

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.

zaphar• 12 years ago

I'll just leave these here: https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8...

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.

ianlancetaylor3• 12 years ago

The fact that it's not necessary to explicitly state which interfaces are implemented by a type is a key design decision in Go. It's not going to change.

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.

burntsushi18• 12 years ago

You're claiming that they think generics have no value. That is incorrect. They just think there are other things that have more value.[1] In other words, they prefer a different set of trade offs than you do. I don't see how this could be reasonably considered "denial."

[1] http://research.swtch.com/generic

pjmlp13• 12 years ago

Because they focus on Java and C++ on their arguments while forgetting other languages.

frowaway00112• 12 years ago

That link has been debunked over and over and over.

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.

xixixao• 12 years ago

A similar problem with CoffeeScript (conflation of declaration and assignment + scope rules)

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.

frowaway00112• 12 years ago

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.

jrockway2• 12 years ago

My understanding is that the Go team says they can't figure out how to make generics work nicely, that's why they haven't added them.

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.

frowaway00112• 12 years ago

That's basically what Java said in 1995.

There is a reason why Java completely abandoned that position.

disputin3• 12 years ago

"...incapable of admitting problems..."

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.

https://golang.org/doc/faq#generics

frowaway00112• 12 years ago

If you read the link you posted, you would know why people say that Go devs are incapable of admitting issues.

sagichmal3• 12 years ago

    > Go doesn't let you build abstractions - it offers what 
    > it does, and if its not enough - tough luck.

This seems contradictory. Go offers primitives, and lets you build exactly the abstractions that make sense in your domain on top of those primitives. The argument here appears to be that the primitives are too low-level, which is a fair-enough point, but not at all what you're claiming.

frowaway00112• 12 years ago

No, your parent is right.

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.

swah2• 12 years ago

I also find Go pragmatic but lacking abstraction power. The other day I needed a stack, and the best solution I could find was this: https://groups.google.com/d/msg/golang-nuts/iwlzqNa4h3g/xCy3...

    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 
    }

And that's what I'm using...

NateDad9• 12 years ago

It's 10 lines of very obvious code. Isn't that a good thing? Do you really need stack.New<T>()?

dirtyaura• 12 years ago

This is in an interesting contrast with Apple's Swift. It seems that Chris Lattner and the Swift team are very willing to listen the input from users in this early phase of the language. The whole way the Swift is being developed is unlike anything else Apple does. Swift core team responds to you in Twitter. The product is released in such an early state that it is frustratingly buggy and slow to use. But it has a regular release schedule and it gets improved in both stability and speed every other week. I don't know if this was agreed on the top level, or did Chris just has enough decision power to just go with this more modern style of release cycle.

tagrun• 12 years ago

You sound confused. Denying the existence of a problem and not wanting a particular proposed solution are not the same thing.

georgemcbay3• 12 years ago

"I want all this <-done synchronizations and select sacramentals to be entire hidden"

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.

dkarapetyan4• 12 years ago

What exactly do you mean by "magic"? Most of the time when I hear people talk about "magic" they usually mean a theory or abstraction that they don't understand or don't want to understand. Are generics magical in your opinion?

georgemcbay3• 12 years ago

What makes things magical or not (the way I think of magical) isn't about the theory of the feature but rather how they are implemented and how much is hidden from the person using them in terms of code complexity and just overall work being done relative to what they think they did.

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".

wyager• 12 years ago

Go doesn't prevent "magic", it just makes you hide the magic in ugly places.

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{}.

georgemcbay3• 12 years ago

It doesn't "prevent" "magic", but it "highly discourages" it.

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.

djur8• 12 years ago

Go has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own.

This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.

nknighthb4• 12 years ago

If there's any magic on that list, it's limited to the garbage collector, and to whatever extent it's magic, that magic would vanish if it were based on strict automatic reference counting.

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.

burntsushi18• 12 years ago

but it's unsurprisingly frustrating for people used to more expressive languages

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.

MoOmer• 12 years ago

I pasted this in the gist comments, and I'll reproduce it here from Hoare's Communicating Sequential Processes: [0]

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

ericflo• 12 years ago

I think the author could use a technique like this to build the higher level abstractions they want: http://commandcenter.blogspot.nl/2014/01/self-referential-fu...

ufo4• 12 years ago

I remember seeing that post a while ago on Reddit. The impression I got from the discussion is that the whole "self-referential" thing was unnecessary and that the code would be much simpler in a language with generics.

http://www.reddit.com/r/programming/comments/1w2y01/rob_pike...

skybrian2• 12 years ago

Rather than arguing about generics in Go again, I'd be interested in reading about how experienced Go developers solve the problems posed in this article. (He may be wrong that there's no elegant solution.)

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.

Rapzid• 12 years ago

Were there any unresolved issues? I really just couldn't tell, it all looked like general learning curve stuff to me(standard stuff you have to think about when using Go) and that he was lambasting how he chose to implement and what he had to go through to do it.

cdoxsey• 12 years ago

In my experience solutions generally fall into two camps:

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{}

Then call it:

   merged := merge(c1, c2, c3).(<-chan int)

You lose type safety and pay some penalty for performance. Also merge is harder to write than it would be with generics.

But even languages with generics often have similar issues. For example you can't write a generic min/max in C# either.

tel4• 12 years ago

You can in Haskell

    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

You can in OCaml

    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

Point being that these problems with generics are reasonably solved. There are perhaps other problems, of course. OCaml should at least be a suggestion that compilation speed isn't really one of them.

jerf3• 12 years ago

There's no generalized solution to every generic problem. The "cast to interface{}" is the closest to a linear mapping of generics, but if you're reaching for that all the time, you're doing it wrong. So the only sane answer is, "it depends".

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.

nickik4• 12 years ago

Interessting. I have not done any go. Could you review go in spirit of you beeing a FP guy? Why does go make it so hard?

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.

skybrian2• 12 years ago

Talking about how to implement generics generically isn't really responding to my question. The original post had questions about how to implement specific concurrent constructs like pipelines, futures, and so on. So the question is how do you handle concurrency in Go? Are we missing important features that should be part of the language or standard libraries?

Some of these may be one-off generic functions like append() that could be added to the language without adding full-blown generics.

ianlancetaylor3• 12 years ago

I think that experienced Go programmers simply write the code using the types they need.

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.

zak_mc_kracken2• 12 years ago

Pretty much every article that is posted about Go ends up in a never ending discussion about the absence of generics, which completely drowns the discussions about Go. As a result, the material on the web about Go has a very high noise/signal ratio, which is unfortunate.

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.

rdtsc4• 12 years ago

Pretty much every article that is posted about Go ends up in a never ending discussion about the absence of generics

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.

ianlancetaylor3• 12 years ago

I have to credit this as being one of the more original arguments for adding generics to Go: we should do it because it will increase the signal/noise ratio in discussions about Go.

(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.)

zak_mc_kracken2• 12 years ago

Yeah I was trying to insufflate new life in this tired debate, glad someone noticed :)

toleavetheman2• 12 years ago

The interesting thing about Go, that can help make sense of all its oddities, is that it was not created to assist the developer.

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_af6• 12 years ago

I understand not having any fancy features in a "corporate programming language", but wouldn't language features aimed at reducing code duplication (like generics) help with maintainability?

toleavetheman2• 12 years ago

I think the extra flexibility gained would be perceived as a negative. The ideal (from their perspective) is that there is only one way to do a particular thing, no matter how verbose it is. Google has recently been mostly Java (Guice, dependency injection everywhere), and has long preferred incredibly verbose code at the cost of occasional duplication.

disputin3• 12 years ago

I stopped reading. The further I got the more the article seemed to be complaining not about channels but that Go isn't a functional language. That's right, it isn't.

mavelikara• 12 years ago

In an essay titled "Why Pascal is Not My Favorite Programming Language" Brian W. Kernighan wrote:

<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;

then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both.

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.

[1] http://www.lysator.liu.se/c/bwk-on-pascal.html

Channels Are Not Enough

Related Stories