5 ms·

I guess having to reimplement basic algorithms for every new container type is an example of avoiding complexity then?

cjslep 12y ago
From the article: > Go isn’t perfect for every task. [...] Ultimately, it is up to you and your team to decide the best language and tools with which to build your application. While making that decision, I hope that you will take a moment to weigh the trade-offs that come with your choices. It's a tradeoff based on your real, hard needs. If you decide that only having Array<T> and Map<T> is a deal breaker, and the complexity of creating a tool to autogenerate the go code for a large number of SinglyLinkedList<T>/DoublyLinkedList<T>/CircularLinkedList<T>/etc... outweighs the uses of Go, then don't use Go. If you are fine writing a quick dirty code generator that can look for some <T>-like syntax and do simple replacement, or only really need Array<T> and Map<T>, then consider Go. It's not like the language is forcing you to use it against your will.
- account_306 12y ago
  Not yet, anyway.
- xg15 12y ago
  > If you decide that only having Array<T> and Map<T> is a deal breaker, and the complexity of creating a tool to autogenerate the go code for a large number of SinglyLinkedList<T>/DoublyLinkedList<T>/CircularLinkedList<T>/etc... outweighs the uses of Go, then don't use Go. With all due respect, but how is having to build a custom code-generator first, before you can write your actual program not accidental complexity?
  - cjslep 12y ago
    I wasn't claiming it isn't accidental complexity. Just pointing out the author essentially says to weigh the decision appropriately. Looking at the sibling comment about "go generate" by buro9, it looks like a custom code-generator won't be needed either. EDIT: Added buro9, and emphasis
dilap 12y ago
Come now -- you don't have to re-implement containers for specific type in Go any more than you do in, say, Python -- you just have to cast when you remove objects from the container. Not great, since you're losing compile-time safety for the type -- but no worse than every single line written in a "dynamic" language like Python, and no worse than pre-generics java, say, or obj-c.
- dons 12y ago
  > no worse than pre-generics java exactly.
- deleted 12y ago
  [deleted]
- m0th87 12y ago
  Python's dynamic typing saves you a lot over static typing without parametric polymorphism, as in Go's case. As a concrete example, take sorting. In Go, you have to implement `sort.Interface` for each custom type you define. An example taken from the `sort` package: package main import ( "fmt" "sort" ) type Person struct { Name string Age int } func (p Person) String() string { return fmt.Sprintf("%s: %d", p.Name, p.Age) } // ByAge implements sort.Interface for []Person based on // the Age field. type ByAge []Person func (a ByAge) Len() int { return len(a) } func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] } func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age } func main() { people := []Person{ {"Bob", 31}, {"John", 42}, {"Michael", 17}, {"Jenny", 26}, } fmt.Println(people) sort.Sort(ByAge(people)) fmt.Println(people) } An equivalent in Python is quite a bit simpler: class Person(object): def __init__(self, name, age): self.name = name self.age = age def __repr__(self): return "%s: %s" % (self.name, self.age) people = [ Person("Bob", 31), Person("John", 42), Person("Michael", 17), Person("Jenny", 26), ] print people people.sort(key=lambda person: person.name) print people If it were just sorting, it wouldn't be that big of a deal. But there's a lot of nice abstractions missing from Go due to the lack of generics - e.g. higher-order functions like `map`.
buro9 12y ago
go generate is in 1.4 which will arrive shortly The proposal (the implementation is pretty much this) is here: https://docs.google.com/a/golang.org/document/d/1V03LUfjSADDooDMhe-_K59EgpTEm3V8uvQRuNMAEnjg/edit?pli=1 https://docs.google.com/a/golang.org/document/d/1V03LUfjSADD... If you feel a real strong need for generics, for something like a "sort by property of my custom type... do it for n types", then it's now trivial to generate that. You can code like you have the features the core doesn't support, whilst having the succinctness, performance and maintainability that the language delivers. I've coded Go almost daily for 2+ years and only a couple of times had the urge/need for generics... I dunno, maybe I'm the exception here.
- bradgignac 12y ago
  I've had the same experience - very little need for generics in Go on a regular basis. I really appreciated the following snippet from http://robnapier.net/go-is-a-shop-built-jig http://robnapier.net/go-is-a-shop-built-jig: "Probably the biggest complaint people have with Go is the lack of generics. And I did run into that in just the first couple of weeks of work on my project, and I wound up with a bunch of duplicated code to work around it. And then, when it was all working, I refactored out the duplicated code. And I refactored again. And in the end, the whole thing was simpler and shorter than what I would have done with generics. So again, in the end, Go turned out to be a language for solving real problems rather than a language filled with beautiful tools, and so you build real solutions rather than finding excuses to use your beautiful tools. Don’t try to make Go what it isn’t. If you’re trying to solve abstract CS problems in their most generalized forms, then you may find it frustrating. But if you’re trying to solve specific, practical problems in the forms professional developers typically encounter, Go is quite nice."
  - mike_hearn 12y ago
    So ..... he ended up doing far more work than he would have done had Go been like any other modern language? Without detail about what these refactorings were and why he didn't write the code that way at first, what lessons he drew from it etc this anecdote is not very useful.
- 12y ago
melling 12y ago
People need to start downvoting the "Go doesn't have generics" trolls. This has been addressed many times. If it really is a showstopper for you, that's fine. There's no value in trolling Go submissions.
- erikpukinskis 12y ago
  Is there some rule that only people who are done talking about generics may participate in conversations about Go? I was happy to see this discussion here.
  - melling 12y ago
    It's your "Ground Hog Day". I'm not sure how much more there is to get out of the comment: "Go doesn't have generics, doesn't work for me."
voidlogic 12y ago
I write Go all day every day and have since before Go 1.0, and I see this troll/complaint at least 100x on hacker news for each time I have to do it once in real life. On the rare event this actually matters I use templating tools if performance is needed, but if not (which is usually the case) I use an interface. But like I said, this is so rare. P.S. I write distributed databases / big data engines and distributed content optimizing proxy servers.
- Jare 12y ago
  > I write Go all day every day and have since before Go 1.0, and I see this troll/complaint at least 100x on hacker news for each time I have to do it once in real life I suspect that there is as much trolling in people who complain about generics, as there is survivor bias in those who reply they haven't needed them in X years of go. If you felt that you needed them, you wouldn't have lasted long using go!
  - voidlogic 12y ago
    Those are fair points. I also think major part of the issue here is all the folks that try to write Java/C++/Python,etc in Go, rather than Go in Go. People install Go, write something in Go, paying no mind to go idioms, and complain. It happens on the Go mailing list all the time.
  - NateDad 12y ago
    I truly don't see many people talking about leaving go after getting frustrated with no generics. If this were survivor bias, where are the casualties?
    - Jare 12y ago
      I assume most people who complain about Go's lack of generics have at least tried the language. It doesn't take long to run into your first interface{} and subsequent typecast. So, if you define "leaving Go" as "not switching to it", there are many. :)
rakoo 12y ago
I guess real-world softwares don't need fancy containers other than a list and a map, and when they actually really do need them the copy-paste turns out to not be that much of a burden ?

From the article: > Go isn’t perfect for every task. [...] Ultimately, it is up to you and your team to decide the best language and tools with which to build your application. While making that decision, I hope that you will take a moment to weigh the trade-offs that come with your choices. It's a tradeoff based on your real, hard needs. If you decide that only having Array<T> and Map<T> is a deal breaker, and the complexity of creating a tool to autogenerate the go code for a large number of SinglyLinkedList<T>/DoublyLinkedList<T>/CircularLinkedList<T>/etc... outweighs the uses of Go, then don't use Go. If you are fine writing a quick dirty code generator that can look for some <T>-like syntax and do simple replacement, or only really need Array<T> and Map<T>, then consider Go. It's not like the language is forcing you to use it against your will.

account_306 12y ago
Not yet, anyway.
xg15 12y ago
> If you decide that only having Array<T> and Map<T> is a deal breaker, and the complexity of creating a tool to autogenerate the go code for a large number of SinglyLinkedList<T>/DoublyLinkedList<T>/CircularLinkedList<T>/etc... outweighs the uses of Go, then don't use Go. With all due respect, but how is having to build a custom code-generator first, before you can write your actual program not accidental complexity?
- cjslep 12y ago
  I wasn't claiming it isn't accidental complexity. Just pointing out the author essentially says to weigh the decision appropriately. Looking at the sibling comment about "go generate" by buro9, it looks like a custom code-generator won't be needed either. EDIT: Added buro9, and emphasis

dilap 12y ago

Come now -- you don't have to re-implement containers for specific type in Go any more than you do in, say, Python -- you just have to cast when you remove objects from the container. Not great, since you're losing compile-time safety for the type -- but no worse than every single line written in a "dynamic" language like Python, and no worse than pre-generics java, say, or obj-c.

dons 12y ago
> no worse than pre-generics java exactly.
deleted 12y ago
[deleted]
m0th87 12y ago
Python's dynamic typing saves you a lot over static typing without parametric polymorphism, as in Go's case. As a concrete example, take sorting. In Go, you have to implement `sort.Interface` for each custom type you define. An example taken from the `sort` package: package main import ( "fmt" "sort" ) type Person struct { Name string Age int } func (p Person) String() string { return fmt.Sprintf("%s: %d", p.Name, p.Age) } // ByAge implements sort.Interface for []Person based on // the Age field. type ByAge []Person func (a ByAge) Len() int { return len(a) } func (a ByAge) Swap(i, j int) { a[i], a[j] = a[j], a[i] } func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age } func main() { people := []Person{ {"Bob", 31}, {"John", 42}, {"Michael", 17}, {"Jenny", 26}, } fmt.Println(people) sort.Sort(ByAge(people)) fmt.Println(people) } An equivalent in Python is quite a bit simpler: class Person(object): def __init__(self, name, age): self.name = name self.age = age def __repr__(self): return "%s: %s" % (self.name, self.age) people = [ Person("Bob", 31), Person("John", 42), Person("Michael", 17), Person("Jenny", 26), ] print people people.sort(key=lambda person: person.name) print people If it were just sorting, it wouldn't be that big of a deal. But there's a lot of nice abstractions missing from Go due to the lack of generics - e.g. higher-order functions like `map`.

buro9 12y ago

go generate is in 1.4 which will arrive shortly The proposal (the implementation is pretty much this) is here: https://docs.google.com/a/golang.org/document/d/1V03LUfjSADDooDMhe-_K59EgpTEm3V8uvQRuNMAEnjg/edit?pli=1 https://docs.google.com/a/golang.org/document/d/1V03LUfjSADD... If you feel a real strong need for generics, for something like a "sort by property of my custom type... do it for n types", then it's now trivial to generate that. You can code like you have the features the core doesn't support, whilst having the succinctness, performance and maintainability that the language delivers. I've coded Go almost daily for 2+ years and only a couple of times had the urge/need for generics... I dunno, maybe I'm the exception here.

bradgignac 12y ago
I've had the same experience - very little need for generics in Go on a regular basis. I really appreciated the following snippet from http://robnapier.net/go-is-a-shop-built-jig http://robnapier.net/go-is-a-shop-built-jig: "Probably the biggest complaint people have with Go is the lack of generics. And I did run into that in just the first couple of weeks of work on my project, and I wound up with a bunch of duplicated code to work around it. And then, when it was all working, I refactored out the duplicated code. And I refactored again. And in the end, the whole thing was simpler and shorter than what I would have done with generics. So again, in the end, Go turned out to be a language for solving real problems rather than a language filled with beautiful tools, and so you build real solutions rather than finding excuses to use your beautiful tools. Don’t try to make Go what it isn’t. If you’re trying to solve abstract CS problems in their most generalized forms, then you may find it frustrating. But if you’re trying to solve specific, practical problems in the forms professional developers typically encounter, Go is quite nice."
- mike_hearn 12y ago
  So ..... he ended up doing far more work than he would have done had Go been like any other modern language? Without detail about what these refactorings were and why he didn't write the code that way at first, what lessons he drew from it etc this anecdote is not very useful.
12y ago

melling 12y ago

People need to start downvoting the "Go doesn't have generics" trolls. This has been addressed many times. If it really is a showstopper for you, that's fine. There's no value in trolling Go submissions.

erikpukinskis 12y ago
Is there some rule that only people who are done talking about generics may participate in conversations about Go? I was happy to see this discussion here.
- melling 12y ago
  It's your "Ground Hog Day". I'm not sure how much more there is to get out of the comment: "Go doesn't have generics, doesn't work for me."

voidlogic 12y ago

I write Go all day every day and have since before Go 1.0, and I see this troll/complaint at least 100x on hacker news for each time I have to do it once in real life. On the rare event this actually matters I use templating tools if performance is needed, but if not (which is usually the case) I use an interface. But like I said, this is so rare. P.S. I write distributed databases / big data engines and distributed content optimizing proxy servers.

Jare 12y ago
> I write Go all day every day and have since before Go 1.0, and I see this troll/complaint at least 100x on hacker news for each time I have to do it once in real life I suspect that there is as much trolling in people who complain about generics, as there is survivor bias in those who reply they haven't needed them in X years of go. If you felt that you needed them, you wouldn't have lasted long using go!
- voidlogic 12y ago
  Those are fair points. I also think major part of the issue here is all the folks that try to write Java/C++/Python,etc in Go, rather than Go in Go. People install Go, write something in Go, paying no mind to go idioms, and complain. It happens on the Go mailing list all the time.
- NateDad 12y ago
  I truly don't see many people talking about leaving go after getting frustrated with no generics. If this were survivor bias, where are the casualties?
  - Jare 12y ago
    I assume most people who complain about Go's lack of generics have at least tried the language. It doesn't take long to run into your first interface{} and subsequent typecast. So, if you define "leaving Go" as "not switching to it", there are many. :)

rakoo 12y ago

I guess real-world softwares don't need fancy containers other than a list and a map, and when they actually really do need them the copy-paste turns out to not be that much of a burden ?