12 ms·

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

by spion 12y 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 12y 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.
eloff 12y 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 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.
- spion 12y 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".
  - eloff 12y ago
    I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. I think the worst part is really our natural aversion to code duplication and the ugliness of it. e.g. having to write min/max for integers is pretty ugly (although not as ugly as converting your ints to float64 and using the stdlib min/max.) However, I spent more time thinking that it was ugly than writing min and max. Sure it's ugly, but programming is not art, it's engineering, and Go is a language for engineers.
    - echaozh 12y ago
      I never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.
      - apta 12y ago
        Or the fact that I actually saw someone on the mailing list also implement min() incorrectly due to copy-paste :) > 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.
        pjmlp 12y ago
        It was the community attitude towards generics and code distribution that eventually made me focus on Rust and D. At least those communities embrace modern computing abstractions and code distribution practices.
cjslep 12y 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 http://golang.org/doc/faq#generics
- spion 12y 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?
  - cjslep 12y ago
    I don't have the hard numbers to back up the cost question, but I believe one contributing factor to the claims appearing "naive/disingenuous" to you may stem from the fact that you may be looking at the language Go from a totally different perspective than the creators when they first envisioned the language (I could be very wrong in this regard): "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 So while I can see generics helping their goal of, say "duplication of effort", I can also see it negatively impacting bullets "different subsets of the language" and maybe "poor programming understanding" since debugging generics can be extra-painful. I might not agree with the way they value generics but to me, it does seem reasonable given their design vision and goals. [0] https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
deleted 12y ago
[deleted]
enneff 12y 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.
- spion 12y ago
  I think that the "complexity" cost of generics is overstated, really. Can you explain how generics make user code more complex?
  - tomlu 12y ago
    They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it elsewhere. (Note that I am in disagreement - I do think generics should be added).
    - nf 12y ago
      No, that is not what I was referring to. It is definitely user code complexity that turns us away from generics. People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.
      - spion 12y ago
        I'd say people tie themselves in inheritance and interface knots more often than generics knots. Especially invariant generics are rather hard to get wrong - they place such constraints on the types that most operations are unavailable.
haberman 12y 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 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 12y ago
  I'll just leave these here: https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8/fgJ8a0tW1xcJ https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8... https://github.com/clipperhouse/gen 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.
  - ufo 12y ago
    TBH, neither of those solve the same problem generics / parametric polymorphism were created to solve: being able to abstract over types when writing a function or data structure. 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.
burntsushi 12y 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 http://research.swtch.com/generic
- pjmlp 12y ago
  Because they focus on Java and C++ on their arguments while forgetting other languages.
- frowaway001 12y 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.
  - burntsushi 12y ago
    > That link has been debunked over and over and over. 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.
    - frowaway001 12y ago
      > The only point that post is making is that generics have a cost. Are you saying that is false? 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.
xixixao 12y 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.
- frowaway001 12y 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.
jrockway 12y 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.
- frowaway001 12y ago
  That's basically what Java said in 1995. There is a reason why Java completely abandoned that position.
  - jrockway 12y ago
    Did Java make generics work nicely, or did they just bolt them on?
disputin 12y 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 https://golang.org/doc/faq#generics
- frowaway001 12y ago
  If you read the link you posted, you would know why people say that Go devs are incapable of admitting issues.
  - disputin 12y ago
    Seriously? "...we understand some programmers do... ...we continue to think about it... ...This remains an open issue."
sagichmal 12y 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.
- frowaway001 12y 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.
dirtyaura 12y 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.
swah 12y 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/xCy3G2V-xwkJ 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...
- NateDad 12y ago
  It's 10 lines of very obvious code. Isn't that a good thing? Do you really need stack.New<T>()?
  - swah 12y ago
    Yes, I do think so. Then I could keep thinking about the "business problem" instead of googling for half an hour because I can't believe there is no one reuses a stack in Go. 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.
tagrun 12y ago
You sound confused. Denying the existence of a problem and not wanting a particular proposed solution are not the same thing.

by spion 12y ago

kyrra 12y 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.

eloff 12y 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 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.

spion 12y 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".
- eloff 12y ago
  I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. I think the worst part is really our natural aversion to code duplication and the ugliness of it. e.g. having to write min/max for integers is pretty ugly (although not as ugly as converting your ints to float64 and using the stdlib min/max.) However, I spent more time thinking that it was ugly than writing min and max. Sure it's ugly, but programming is not art, it's engineering, and Go is a language for engineers.
  - echaozh 12y ago
    I never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.
    - apta 12y ago
      Or the fact that I actually saw someone on the mailing list also implement min() incorrectly due to copy-paste :) > 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.
      - pjmlp 12y ago
        It was the community attitude towards generics and code distribution that eventually made me focus on Rust and D. At least those communities embrace modern computing abstractions and code distribution practices.

cjslep 12y 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 http://golang.org/doc/faq#generics

spion 12y 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?
- cjslep 12y ago
  I don't have the hard numbers to back up the cost question, but I believe one contributing factor to the claims appearing "naive/disingenuous" to you may stem from the fact that you may be looking at the language Go from a totally different perspective than the creators when they first envisioned the language (I could be very wrong in this regard): "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 So while I can see generics helping their goal of, say "duplication of effort", I can also see it negatively impacting bullets "different subsets of the language" and maybe "poor programming understanding" since debugging generics can be extra-painful. I might not agree with the way they value generics but to me, it does seem reasonable given their design vision and goals. [0] https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article

deleted 12y ago

[deleted]

enneff 12y 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.

spion 12y ago
I think that the "complexity" cost of generics is overstated, really. Can you explain how generics make user code more complex?
- tomlu 12y ago
  They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it elsewhere. (Note that I am in disagreement - I do think generics should be added).
  - nf 12y ago
    No, that is not what I was referring to. It is definitely user code complexity that turns us away from generics. People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.
    - spion 12y ago
      I'd say people tie themselves in inheritance and interface knots more often than generics knots. Especially invariant generics are rather hard to get wrong - they place such constraints on the types that most operations are unavailable.

haberman 12y 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 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 12y ago
I'll just leave these here: https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8/fgJ8a0tW1xcJ https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8... https://github.com/clipperhouse/gen 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.
- ufo 12y ago
  TBH, neither of those solve the same problem generics / parametric polymorphism were created to solve: being able to abstract over types when writing a function or data structure. 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.

burntsushi 12y 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 http://research.swtch.com/generic

pjmlp 12y ago
Because they focus on Java and C++ on their arguments while forgetting other languages.
frowaway001 12y 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.
- burntsushi 12y ago
  > That link has been debunked over and over and over. 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.
  - frowaway001 12y ago
    > The only point that post is making is that generics have a cost. Are you saying that is false? 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.

xixixao 12y 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.

frowaway001 12y 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.

jrockway 12y 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.

frowaway001 12y ago
That's basically what Java said in 1995. There is a reason why Java completely abandoned that position.
- jrockway 12y ago
  Did Java make generics work nicely, or did they just bolt them on?

disputin 12y 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 https://golang.org/doc/faq#generics

frowaway001 12y ago
If you read the link you posted, you would know why people say that Go devs are incapable of admitting issues.
- disputin 12y ago
  Seriously? "...we understand some programmers do... ...we continue to think about it... ...This remains an open issue."

sagichmal 12y 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.

frowaway001 12y 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.

dirtyaura 12y 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.

swah 12y 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/xCy3G2V-xwkJ 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...

NateDad 12y ago
It's 10 lines of very obvious code. Isn't that a good thing? Do you really need stack.New<T>()?
- swah 12y ago
  Yes, I do think so. Then I could keep thinking about the "business problem" instead of googling for half an hour because I can't believe there is no one reuses a stack in Go. 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.

tagrun 12y ago

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