7 ms·

I think this just highlights how massive a mistake the Go developers made not including generics from Day 1. It was a mistake in Java that they corrected with

I think this just highlights how massive a mistake the Go developers made not including generics from Day 1. It was a mistake in Java that they corrected with a lot of pain. It is a mistake in Go they are going to correct and most likely with a lot of pain. If they cannot do it seamlessly it may end up being a Python 2/3 platform split. Those who fail to learn from history are doomed to repeat it.

baby 6y ago
I'd say the popularity of Go stems from the lack of generics.
- xkapastel 6y ago
  And why on earth would you say that?
  - baby 6y ago
    because it's a breeze to read Golang, due in parts to the lack of generics
    - therealdrag0 6y ago
      Why does genetics make things that’s for read?
      - zdragnar 6y ago
        Functions can be given semantic names (I.e. have meaning); block statements cannot. If writing a function that can take an array or slice of any type of data requires providing a generic argument (I.e. so you can specify that the function returns a slice of the same type of data as it was given), then you can name it "reverse" if it reverses the array, write it only once, and every timr you use it, you read "reverse" and know what it does. For loops dont have those names, and so have to be rewritten every time you use them. As such, every time you see a for loop, you have to read and parse every statement to see what it is doing, and if it has any unexpected side effects or bugs introduced via copy-paste or what not.
        therealdrag0 6y ago
        Sorry I meant to say “why do genetics make things harder to read?”. Tbh I can’t tell if you’re responding to that or not
        zdragnar 6y ago
        I did misread your post, but I will also say that generics are a double edged sword when it comes to readability. Needing to declare genetic types in function signatures can add irrelevant detail and heavy syntax. For example, look at the interpreter interface in this typescript file: https://github.com/gcanti/io-ts/blob/master/src/Schema.ts#L29 https://github.com/gcanti/io-ts/blob/master/src/Schema.ts#L2... Granted, genetics don't need to be done that way, but it is among the more common and popular approaches. The type information is tangled up in the implementation, making focusing on either more challenging. Perhaps we need modes for syntax highlighting- one for types, one for implementation?
    - hombre_fatal 6y ago
      Lack of generics just means you have to copy and paste everything, like any time you want to reverse a slice. for i := len(a)/2 - 1; i >= 0; i-- { opp := len(a) - 1 - i a[i], a[opp] = a[opp], a[i] } Actively hurts reading code as you have to credentialize in a code base to begin to be able to file entire code blocks into copy and pasted "idioms". Without generics you have to hope the stdlib gets a blessed generic function like reverse() one day since you can't build one without rolling your own monomorphization code-gen or a goofball interface{}+cast hack. For people who supposedly prefer the lack of generics (which seems more like cargo culting or Stockholm Syndrome), no problem. We can just add a config option to golint that prohibits you from using generics. That way you don't need to hold up the rest of us. win-win.
      - psanford 6y ago
        Weird. While you could copy that from the SliceTricks Go wiki page, you could also just use `sort.Sort(sort.Reverse())` which seems to address all of your complaints.
        littlestymaar 6y ago
        But it uses an interface, which means dynamic dispatch and an allocation most of the time (because IIRC it tends to break the escape analysis). That's a recurrent issue with Go: you can either have ergonomic tools (with interface and reflection), or performant code (with no allocation) but you generally can't have both at the same time. Sure it's better than scripting language where you need to use another language when you need performance, but it's still kind of sad.
- pcwalton 6y ago
  No, it doesn't. Go is popular because of the names and organization behind it, as well as the fact that it's useful for a lot of people despite the lack of generics. Certainly, a lot of people are attracted to Rob Pike's rather idiosyncratic preferences, tastes, and nostalgia for the early days of Unix, which are on display in a lot of Go's design decisions, like the lack of generics. But lots of random people have preferences and nostalgia for all sorts of things; we usually only pay attention to such things when it's a person with a famous pedigree who has them.
  - baby 6y ago
    at least to me, the lack of generics was a benefit. I'm probably not alone :)
  - tptacek 6y ago
    The "names and organization behind it" thing is needlessly condescending (not to mention false), and the ability to get things done without generics basically restates David's point. Was there something in this paper that you felt unfairly treated Rust, the language you represent on these threads? Because otherwise, I can't see what would motivate you to join this thread to snipe. I'm with David, for what it's worth. Lack of generics has mostly helped me be productive in Go, and the extreme prevalence of generics in every Rust library I deal with has definitely slowed me down a bit. I'm looking forward to generics support in Go, but mostly for what I hope it does to message board threads.
    - pcwalton 6y ago
      I went out of my way to make the point without condescension. Evidently I didn't succeed, and I'm sorry for that! Let me put it another way: Virtually all languages that have become popular recently have done so because of the backing of some large organization or another. There was a time when languages like Perl, Python, and PHP could arise out of basically nowhere and become popular. That time is gone, and now languages essentially need organizational backing of some kind to succeed. That was true for TypeScript, it was true for Rust, it was true for Swift, it was true for Kotlin, and it was true for Go. They also benefit from some sort of well-known thought leader, a role that Rob Pike plays well. If you think Go would have gotten popular without having a Google and a Rob Pike behind it, then, well, I don't know what to tell you. I don't think Rust would have been popular either without the Mozilla association. Or, more succinctly: I see no world in which Go having simple ML-style generics, without typeclasses or functors, would have made it any less popular. Other factors dominate when it comes to success of a programming language. TypeScript, in fact, shows that you can have generics that are more complex than those of Rust and still become wildly popular.
skybrian 6y ago
It's not at all clear that it was a mistake. Go has had eight years of being one of the more successful languages. If they had tried implementing generics right away, it may have taken longer and it's unclear whether Google would have supported the work for so long? Maybe the timing would have been different enough that they didn't succeed, or the lack of experience would have resulted in a design that's worse? It's also not at all clear that Go will have similar problems as Python did, since the Go team considers backward compatibility important and might approach the problem differently, learning from Python what to avoid. Counterfactual reasoning is difficult. Learning from history isn't as easy as some make it look.
- thesz 6y ago
  It was successful due to massive amount of money spent by Google. Because there were languages that are much better suited for what Go was designed for. To name a few: Erlang (concurrency that is better than Go's, "channels" and types on par with Go with Dialyzer), Haskell (thread concurrency better than Erlang's, channels, transaction memory, etc and types well beyond Go) and many others. Go was successful despite mistakes.

baby 6y ago

I'd say the popularity of Go stems from the lack of generics.

xkapastel 6y ago
And why on earth would you say that?
- baby 6y ago
  because it's a breeze to read Golang, due in parts to the lack of generics
  - therealdrag0 6y ago
    Why does genetics make things that’s for read?
    - zdragnar 6y ago
      Functions can be given semantic names (I.e. have meaning); block statements cannot. If writing a function that can take an array or slice of any type of data requires providing a generic argument (I.e. so you can specify that the function returns a slice of the same type of data as it was given), then you can name it "reverse" if it reverses the array, write it only once, and every timr you use it, you read "reverse" and know what it does. For loops dont have those names, and so have to be rewritten every time you use them. As such, every time you see a for loop, you have to read and parse every statement to see what it is doing, and if it has any unexpected side effects or bugs introduced via copy-paste or what not.
      - therealdrag0 6y ago
        Sorry I meant to say “why do genetics make things harder to read?”. Tbh I can’t tell if you’re responding to that or not
        zdragnar 6y ago
        I did misread your post, but I will also say that generics are a double edged sword when it comes to readability. Needing to declare genetic types in function signatures can add irrelevant detail and heavy syntax. For example, look at the interpreter interface in this typescript file: https://github.com/gcanti/io-ts/blob/master/src/Schema.ts#L29 https://github.com/gcanti/io-ts/blob/master/src/Schema.ts#L2... Granted, genetics don't need to be done that way, but it is among the more common and popular approaches. The type information is tangled up in the implementation, making focusing on either more challenging. Perhaps we need modes for syntax highlighting- one for types, one for implementation?
  - hombre_fatal 6y ago
    Lack of generics just means you have to copy and paste everything, like any time you want to reverse a slice. for i := len(a)/2 - 1; i >= 0; i-- { opp := len(a) - 1 - i a[i], a[opp] = a[opp], a[i] } Actively hurts reading code as you have to credentialize in a code base to begin to be able to file entire code blocks into copy and pasted "idioms". Without generics you have to hope the stdlib gets a blessed generic function like reverse() one day since you can't build one without rolling your own monomorphization code-gen or a goofball interface{}+cast hack. For people who supposedly prefer the lack of generics (which seems more like cargo culting or Stockholm Syndrome), no problem. We can just add a config option to golint that prohibits you from using generics. That way you don't need to hold up the rest of us. win-win.
    - psanford 6y ago
      Weird. While you could copy that from the SliceTricks Go wiki page, you could also just use `sort.Sort(sort.Reverse())` which seems to address all of your complaints.
      - littlestymaar 6y ago
        But it uses an interface, which means dynamic dispatch and an allocation most of the time (because IIRC it tends to break the escape analysis). That's a recurrent issue with Go: you can either have ergonomic tools (with interface and reflection), or performant code (with no allocation) but you generally can't have both at the same time. Sure it's better than scripting language where you need to use another language when you need performance, but it's still kind of sad.
pcwalton 6y ago
No, it doesn't. Go is popular because of the names and organization behind it, as well as the fact that it's useful for a lot of people despite the lack of generics. Certainly, a lot of people are attracted to Rob Pike's rather idiosyncratic preferences, tastes, and nostalgia for the early days of Unix, which are on display in a lot of Go's design decisions, like the lack of generics. But lots of random people have preferences and nostalgia for all sorts of things; we usually only pay attention to such things when it's a person with a famous pedigree who has them.
- baby 6y ago
  at least to me, the lack of generics was a benefit. I'm probably not alone :)
- tptacek 6y ago
  The "names and organization behind it" thing is needlessly condescending (not to mention false), and the ability to get things done without generics basically restates David's point. Was there something in this paper that you felt unfairly treated Rust, the language you represent on these threads? Because otherwise, I can't see what would motivate you to join this thread to snipe. I'm with David, for what it's worth. Lack of generics has mostly helped me be productive in Go, and the extreme prevalence of generics in every Rust library I deal with has definitely slowed me down a bit. I'm looking forward to generics support in Go, but mostly for what I hope it does to message board threads.
  - pcwalton 6y ago
    I went out of my way to make the point without condescension. Evidently I didn't succeed, and I'm sorry for that! Let me put it another way: Virtually all languages that have become popular recently have done so because of the backing of some large organization or another. There was a time when languages like Perl, Python, and PHP could arise out of basically nowhere and become popular. That time is gone, and now languages essentially need organizational backing of some kind to succeed. That was true for TypeScript, it was true for Rust, it was true for Swift, it was true for Kotlin, and it was true for Go. They also benefit from some sort of well-known thought leader, a role that Rob Pike plays well. If you think Go would have gotten popular without having a Google and a Rob Pike behind it, then, well, I don't know what to tell you. I don't think Rust would have been popular either without the Mozilla association. Or, more succinctly: I see no world in which Go having simple ML-style generics, without typeclasses or functors, would have made it any less popular. Other factors dominate when it comes to success of a programming language. TypeScript, in fact, shows that you can have generics that are more complex than those of Rust and still become wildly popular.

skybrian 6y ago

It's not at all clear that it was a mistake. Go has had eight years of being one of the more successful languages. If they had tried implementing generics right away, it may have taken longer and it's unclear whether Google would have supported the work for so long? Maybe the timing would have been different enough that they didn't succeed, or the lack of experience would have resulted in a design that's worse? It's also not at all clear that Go will have similar problems as Python did, since the Go team considers backward compatibility important and might approach the problem differently, learning from Python what to avoid. Counterfactual reasoning is difficult. Learning from history isn't as easy as some make it look.

thesz 6y ago
It was successful due to massive amount of money spent by Google. Because there were languages that are much better suited for what Go was designed for. To name a few: Erlang (concurrency that is better than Go's, "channels" and types on par with Go with Dialyzer), Haskell (thread concurrency better than Erlang's, channels, transaction memory, etc and types well beyond Go) and many others. Go was successful despite mistakes.