6 ms·

> It doesn't matter how clever those features are, overall simplicity and consistency matters more. You mean, except the lack of simplicity when you have gener

by tomp 12y ago

> It doesn't matter how clever those features are, overall simplicity and consistency matters more. You mean, except the lack of simplicity when you have generic arrays and maps, and the lack of consistency when no other type can be generic? (Personally, I don't think generics are complicated, but people say that Go designers think so.)

GhotiFish 12y ago
boy I hear you there. That drives me completely insane about Go. They choose to have generics in these specific instances because if they didn't the language would be cumbersome. It's not enough.
NateDad 12y ago
It's still a vastly simpler language than pretty much any other widely used language out there. Consistency is superseded by pragmatism in the language design.
- latch 12y ago
  C ?
  - norswap 12y ago
    Go actually manages to be less powerful than C. You could do this generic stuff with macros in C. Honestly, Go is probably one of the only language that is clearly not expressive enough.
    - masklinn 12y ago
      Well it's pretty close to Java pre-1.5, which I guess was fine back in the 90s.
      - NateDad 12y ago
        Except go has value types and closures and first class functions and implicit interfaces and multiple return values....
        NateDad 12y ago
        Oh yeah, and generic lists and maps And built-in testing infrastructure, performance testing, code distribution, linting, code formatting, parsing and AST libraries...
        papaf 12y ago
        And a built in dependency manager, build tool, documentation generator...
        dkarapetyan 12y ago
        But generics crosses the line because compile-time code generation is so much clearer and simpler and doesn't add any overhead to compilation times because code substitution is not compilation.
        pjmlp 12y ago
        pre-Java 1.5 already had all of that.
        burntsushi 12y ago
        Where was pre-Java 1.5's generic HashMap? Or closures?
        pjmlp 12y ago
        > Where was pre-Java 1.5's generic HashMap? In java.util.Hashtable as implementation of the java.util.Dictionary interface, since version 1.1 back in 1997. Implemented using s/interface{}/Object/g with ability to use any type as key, as long as, hashCode() and equals () are overriden. Also allows for fine tuning of the capacity and load factor. > Or closures? In anonymous inner classes. A pain to use when compared with real closures, but doable nonetheless.
    - zuzun 12y ago
      I'm sorry but this is utter nonsense and shows the quality of most "Go lacks generics" discussions. Go manages to do so many things so much better than C [0], the boldness of your statement leaves me speechless. [0] Just to name a few: Go has packages instead of header files, one simple build command instead of Makefiles, embedded structs, interfaces, allows you to declare functions everywhere, multiple return values, panics, a huge (!) platform independent standard library, native platform independent concurrency, saner string handling, lists, dictionaries, iota, cross-platform and cross-architecture code via file names instead of macros + autotools, ... I really can't understand how people dismiss all of this and claim a programming language is useless because it lacks a single feature.
      - pessimizer 12y ago
        I think that when you call something utter nonsense, and name a lot of reasons why you think it's utter nonsense, you should be obligated to explain at least one. It's not clear why the features you mention are better than their C equivalents.
        NateDad 12y ago
        Uh, which of those aren't just blatantly obvious? (Totally serious question)
        pessimizer 12y ago
        None of them are obvious to me at that level of detail. (Totally serious answer)
      - norswap 12y ago
        You misunderstand me. I am not saying C does things better than Go. I am saying it is less expressive. In the sense that there are a lot of things you simply cannot implement in C, whereas you can implement them -- in an ugly and unsafe fashion, it is true -- in C. Generics is not the only example. You can easily get exceptions in C with setjmp and longjmp for instance. You can even get garbage collection in C (and not only talking about the conservative Boehm stuff, you can use fat pointers -- yes it's unwieldy and ugly, but it works). As for all the niceties, yes there are there, but you can implement most of them in C also (and, in fact, people have). You'll notice I did not even say C was better than Go. My actual thoughts on the matter is that they're not made for the same use cases -- albeit one of my problem with Go was always figuring its use case. Apparently I'm not the only one confused, because the language creators expected to get C users, they got Python user instead. As you said yourself, it has more niceties, so maybe it is kind of a middleground when more performance or concurrency is needed, but C is deemed to tricky or unsafe. As I have learned to navigate my ways around C's pitfalls (and boy, there are some pitfalls!), I don't think I'll ever be tempted to use Go (at least, if the language doesn't change significantly). I'm also not some kind of C fanatic, I use Java, Ruby or Python if it gets the job done; and while I don't really use them for actual work, I have a soft spot for some functional languages.
kyrra 12y ago
Generics add addition type checking at the the cost of complexity in other areas: syntax, compilation, runtime[0]. Heavily debated there, but what they are trying to get at is that generics have a cost associated with them, adding them is not free. The Go team is trying to search to see if there is some better way to solve this problem right now. As well, from what I've heard of Java's generics implementation, it add a huge amount of complexity to javac and the JRE. The Go team is small and probably didn't have the resources to do it out the gate. [0] http://research.swtch.com/generic http://research.swtch.com/generic
- tomp 12y ago
  I don't think you understood my point. To repeat: there is no cost in adding generics to Go, because they are already there! They are just non-generic (pun intended) - you cannot add it to every type, only to "blessed" types - arrays/slices, channels and maps.
  - burntsushi 12y ago
    > To repeat: there is no cost in adding generics to Go, because they are already there! Could you please stop spreading this nonsense?[1] Generics aren't free. You will always pay for it in terms of some combination of implementation complexity, runtime performance and compiler performance. [1] - https://news.ycombinator.com/item?id=8316995 https://news.ycombinator.com/item?id=8316995
    - tomp 12y ago
      I'm sorry. In all honesty, I have no idea how generics are currently implemented in Go. If you know, I'd kindly ask you to explain why you think the current implementation could not be extended to user-defined types. > Generics aren't free. You will always pay for it in terms of some combination of implementation complexity, runtime performance and compiler performance. I don't argue about implementation complexity and compiler performance, I'm just saying that I assume that most that complexity is already present in the Go compiler. However, I think that saying that generics have runtime performance cost is disingenuous. It's like saying that functions aren't free. Now, obviously it's possible to program without function by using loops, gotos or inlining code. However, if you want to make your program more abstract, you'll end up implementing functions, along with calling conventions, register saving, varargs, ... It's easier if the compiler does that for you (also, sometimes the compiler will compile functions into loops, gotos or inlined code, reducing the performance penalty). It's the same with generics. If you have an algorithm that you want to use with different data types, you can either (1) implement it multiple times, or (2) manually box and unbox all values. That's exactly what the compiler can do for you if you write the code using generics. The fact that most compilers use just one of these strategies is not a deficiency of generics, but the deficiency of compilers. Both Scala and .Net use both specialization and boxing. Therefore, in all honesty, I really see no additional runtime cost to generics that wouldn't be present in equivalent non-generic code.

by tomp 12y ago

GhotiFish 12y ago

boy I hear you there. That drives me completely insane about Go. They choose to have generics in these specific instances because if they didn't the language would be cumbersome. It's not enough.

NateDad 12y ago

It's still a vastly simpler language than pretty much any other widely used language out there. Consistency is superseded by pragmatism in the language design.

latch 12y ago
C ?
- norswap 12y ago
  Go actually manages to be less powerful than C. You could do this generic stuff with macros in C. Honestly, Go is probably one of the only language that is clearly not expressive enough.
  - masklinn 12y ago
    Well it's pretty close to Java pre-1.5, which I guess was fine back in the 90s.
    - NateDad 12y ago
      Except go has value types and closures and first class functions and implicit interfaces and multiple return values....
      - NateDad 12y ago
        Oh yeah, and generic lists and maps And built-in testing infrastructure, performance testing, code distribution, linting, code formatting, parsing and AST libraries...
        papaf 12y ago
        And a built in dependency manager, build tool, documentation generator...
        dkarapetyan 12y ago
        But generics crosses the line because compile-time code generation is so much clearer and simpler and doesn't add any overhead to compilation times because code substitution is not compilation.
        pjmlp 12y ago
        pre-Java 1.5 already had all of that.
        burntsushi 12y ago
        Where was pre-Java 1.5's generic HashMap? Or closures?
        pjmlp 12y ago
        > Where was pre-Java 1.5's generic HashMap? In java.util.Hashtable as implementation of the java.util.Dictionary interface, since version 1.1 back in 1997. Implemented using s/interface{}/Object/g with ability to use any type as key, as long as, hashCode() and equals () are overriden. Also allows for fine tuning of the capacity and load factor. > Or closures? In anonymous inner classes. A pain to use when compared with real closures, but doable nonetheless.
  - zuzun 12y ago
    I'm sorry but this is utter nonsense and shows the quality of most "Go lacks generics" discussions. Go manages to do so many things so much better than C [0], the boldness of your statement leaves me speechless. [0] Just to name a few: Go has packages instead of header files, one simple build command instead of Makefiles, embedded structs, interfaces, allows you to declare functions everywhere, multiple return values, panics, a huge (!) platform independent standard library, native platform independent concurrency, saner string handling, lists, dictionaries, iota, cross-platform and cross-architecture code via file names instead of macros + autotools, ... I really can't understand how people dismiss all of this and claim a programming language is useless because it lacks a single feature.
    - pessimizer 12y ago
      I think that when you call something utter nonsense, and name a lot of reasons why you think it's utter nonsense, you should be obligated to explain at least one. It's not clear why the features you mention are better than their C equivalents.
      - NateDad 12y ago
        Uh, which of those aren't just blatantly obvious? (Totally serious question)
        pessimizer 12y ago
        None of them are obvious to me at that level of detail. (Totally serious answer)
    - norswap 12y ago
      You misunderstand me. I am not saying C does things better than Go. I am saying it is less expressive. In the sense that there are a lot of things you simply cannot implement in C, whereas you can implement them -- in an ugly and unsafe fashion, it is true -- in C. Generics is not the only example. You can easily get exceptions in C with setjmp and longjmp for instance. You can even get garbage collection in C (and not only talking about the conservative Boehm stuff, you can use fat pointers -- yes it's unwieldy and ugly, but it works). As for all the niceties, yes there are there, but you can implement most of them in C also (and, in fact, people have). You'll notice I did not even say C was better than Go. My actual thoughts on the matter is that they're not made for the same use cases -- albeit one of my problem with Go was always figuring its use case. Apparently I'm not the only one confused, because the language creators expected to get C users, they got Python user instead. As you said yourself, it has more niceties, so maybe it is kind of a middleground when more performance or concurrency is needed, but C is deemed to tricky or unsafe. As I have learned to navigate my ways around C's pitfalls (and boy, there are some pitfalls!), I don't think I'll ever be tempted to use Go (at least, if the language doesn't change significantly). I'm also not some kind of C fanatic, I use Java, Ruby or Python if it gets the job done; and while I don't really use them for actual work, I have a soft spot for some functional languages.

kyrra 12y ago

Generics add addition type checking at the the cost of complexity in other areas: syntax, compilation, runtime[0]. Heavily debated there, but what they are trying to get at is that generics have a cost associated with them, adding them is not free. The Go team is trying to search to see if there is some better way to solve this problem right now. As well, from what I've heard of Java's generics implementation, it add a huge amount of complexity to javac and the JRE. The Go team is small and probably didn't have the resources to do it out the gate. [0] http://research.swtch.com/generic http://research.swtch.com/generic

tomp 12y ago
I don't think you understood my point. To repeat: there is no cost in adding generics to Go, because they are already there! They are just non-generic (pun intended) - you cannot add it to every type, only to "blessed" types - arrays/slices, channels and maps.
- burntsushi 12y ago
  > To repeat: there is no cost in adding generics to Go, because they are already there! Could you please stop spreading this nonsense?[1] Generics aren't free. You will always pay for it in terms of some combination of implementation complexity, runtime performance and compiler performance. [1] - https://news.ycombinator.com/item?id=8316995 https://news.ycombinator.com/item?id=8316995
  - tomp 12y ago
    I'm sorry. In all honesty, I have no idea how generics are currently implemented in Go. If you know, I'd kindly ask you to explain why you think the current implementation could not be extended to user-defined types. > Generics aren't free. You will always pay for it in terms of some combination of implementation complexity, runtime performance and compiler performance. I don't argue about implementation complexity and compiler performance, I'm just saying that I assume that most that complexity is already present in the Go compiler. However, I think that saying that generics have runtime performance cost is disingenuous. It's like saying that functions aren't free. Now, obviously it's possible to program without function by using loops, gotos or inlining code. However, if you want to make your program more abstract, you'll end up implementing functions, along with calling conventions, register saving, varargs, ... It's easier if the compiler does that for you (also, sometimes the compiler will compile functions into loops, gotos or inlined code, reducing the performance penalty). It's the same with generics. If you have an algorithm that you want to use with different data types, you can either (1) implement it multiple times, or (2) manually box and unbox all values. That's exactly what the compiler can do for you if you write the code using generics. The fact that most compilers use just one of these strategies is not a deficiency of generics, but the deficiency of compilers. Both Scala and .Net use both specialization and boxing. Therefore, in all honesty, I really see no additional runtime cost to generics that wouldn't be present in equivalent non-generic code.