5 ms·

I agree. Those using Go without generics will go on using it. I would also posit the following though: Those that don't use Go because it lacks things like g

by jpgvm 12y ago

I agree. Those using Go without generics will go on using it. I would also posit the following though: Those that don't use Go because it lacks things like generics aren't likely to use it once they are added either. My personal opinion is Go is a simple language with little to no features of significance. This makes it easy to learn and easy to write. However, it leaves programmers used to higher level and more powerful constructs wanting. If you are used to writing Haskell or even something like Ruby then Go is going to feel like a pretty significant step down. God forbid you are looking at a language like Rust which makes Go look skinny in terms of features indeed. At the end of the day it boils down to what you are happy with using. Is a hammer and nails good enough for you? Or do you prefer a variable speed handheld drill with impact mode and keyless chuck, etc etc etc?

mrcwinn 12y ago
"God forbid you are looking at a language like Rust which makes Go look skinny in terms of features indeed." No disrespect meant to Rust, but it's hardly as simple as saying, "Go lacks Generics! Use Rust!" Rust is far --- far --- from production-worthy. It's certainly settling down into a 1.0, but it has had an extremely volatile standard library and design. There are some early contributors who are doing the "brave work" of using it in production with the aim of bringing it forward to a 1.0, but for the rest of us, it's simply not even in the consideration set. There's also a real question about garbage collection. Rust's "feature set" is surely thicker than Go's - but you need some of those things because you're doing much more work at compile-time. We can argue about the runtime cost of a mature GC (and Go isn't even there yet!), but again, it's not as simple as "use Rust." There's a real productivity cost, I would argue, with doing that extra work and adding that complexity. It doesn't boil down only to what you are happy with using. For the weekend project, it really doesn't matter at all. For a large, production application, there are real, important questions to answer and they matter a great deal. It's not "is a hammer good enough?" - A hammer is hardly good enough when you're staring at screws. I'm not saying one is right or one is wrong. I'm saying choosing a language is usually only something that matters at a certain scale, and at that scale, you have to be very knowledgable and careful.
- jpgvm 12y ago
  I wasn't saying someone should use Rust over Go because of Traits and other generic programming features. I was saying if you are evaluating Rust then Go probably looks very feature light in comparison. Same goes for programmers currently using Java/C# or even Haskell. Go is just a lot less featured than other high performance managed languages that are just as battle tested and just as fast. This is not to say that it's not a good language or the correct tool for a job. Only that those programmers will be left wanting in many areas, generics only being one.
  - NateDad 12y ago
    People who use Java and C# actually have a lot fewer reasons not to use go. The lack of a required runtime applies to both, better cross platform compatibility then C#, and lower memory overhead and faster startup than Java... You lose generics but you gain real value types and better concurrency primitives.
  - deleted 12y ago
    [deleted]
waps 12y ago
I can't believe how they're actually using "Built-in generic types, i.e. the current Go approach (generic types map/chan/slice)" as an argument AGAINST generics. I mean this is unbelievable. Of course that list is not complete, as there are more generic datatypes in Go (arrays, function return value-tuples, ...). Fact is, the golang authors are using generics (and polymorphism, and ...) in the language and in the compiler. So they have answered all the questions about generics : > does it result in a slow compiler ? Obviously not, after all the compiler has generics. > are generic structures less useful ? Well how useful do the Go authors find map/slice/arrays/... the generic Go datatypes ? So obviously this is both a bullshit argument and one people like Rob Pike don't actually believe is true. > Generic structures are less optimized If this is true, then clearly Go's authors find this an acceptable cost. More generally, let's take a look at Rob Pike's example code. For instance here is a talk described as "An hour-long talk delivered by Rob Pike at Google in October 2009. The language's first public introduction." http://talks.golang.org/2009/go_talk-20091030.pdf http://talks.golang.org/2009/go_talk-20091030.pdf First code example that isn't hello world, first function called : if len(str) > 0 { ch = str[0] } A polymorphic function ... weekend := []string{ "Saturday", "Sunday" } timeZones := map[string]TZ { "UTC":UTC, "EST":EST, "CST":CST, //... } Generic data types. Why are we arguing about this ? There is no disagreement between Go's users and authors : Go needs generics. The authors simply don't feel capable of implementing it. How about, like hundred other problems in Go we simply ask ourselves "is this hard to program in a compiler ?", and yes it is. So they put in an ugly hack for their own special cases. This argument, first of all, consistently fits all Go languge decisions leading to the correct conclusion, as opposed to all the arguments given by the Go authors that have no end of exceptions and personal preferences to take into account to arrive at the correct conclusion. Go's authors clearly have some trouble understanding the mathematical foundations of type systems, which is plainly visible in Go's type system. It's inconsistent. Without massive holes in the language, like we currently, this will become VERY visible and move people away from Go.
- threeseed 12y ago
  Shame you were downvoted as it definitely added to the conversation. That said I would disagree that flaws in a type system will result in people moving away from Go. Scala has a type system that is ridiculous complex and has plenty of holes and it doesn't seem to have affected its adoption rate.
wtf_is_up 12y ago
This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile time, language simplicity, toolchain simplicity, maintainability, etc etc For these developers Go can be a good fit. Everybody knows it doesn't have feature parity with Haskell et al from a computer science perspective. If that's all that mattered we would be seeing a lot of Haskell adoption wouldn't we? You shouldn't pick a language based on a checklist.
- coldtea 12y ago
  >This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile time, language simplicity, toolchain simplicity, maintainability, etc etc All of which are orthogonal to having a more modern language, except maybe simplicity. And even for that, after a while you understand that not having, say, generics, pattern matching or some such language feature, is not "simpler" is just having to do more busywork manually and in an error prone way. There's simplicity as in "this is simple to understand and use" and simplicity as in "we ommited some advanced functionality and you'll have to built it by yourself, every time". The second is a false simplicity. As Einstein put it: "we should make things as simple as possible, but not simpler". Pointing to a specific point were making something simpler makes it lose the essense it should have.
  - NateDad 12y ago
    It is simpler. It's like comparing English to German. Sure, in German you can just say "schadenfreude" and in English you have to say "taking joy from someone else's misfortune", but everyone will understand the latter, and many people may misunderstand the former... And even though you may feel smarter for being able to use a big word, if you are writing a legal document that needs to be understood by many people, you're probably better off with the more wordy English.
    - coldtea 12y ago
      >but everyone will understand the latter, and many people may misunderstand the former... And the analogy breaks in that all German speakers will understand the former.

by jpgvm 12y ago

mrcwinn 12y ago

"God forbid you are looking at a language like Rust which makes Go look skinny in terms of features indeed." No disrespect meant to Rust, but it's hardly as simple as saying, "Go lacks Generics! Use Rust!" Rust is far --- far --- from production-worthy. It's certainly settling down into a 1.0, but it has had an extremely volatile standard library and design. There are some early contributors who are doing the "brave work" of using it in production with the aim of bringing it forward to a 1.0, but for the rest of us, it's simply not even in the consideration set. There's also a real question about garbage collection. Rust's "feature set" is surely thicker than Go's - but you need some of those things because you're doing much more work at compile-time. We can argue about the runtime cost of a mature GC (and Go isn't even there yet!), but again, it's not as simple as "use Rust." There's a real productivity cost, I would argue, with doing that extra work and adding that complexity. It doesn't boil down only to what you are happy with using. For the weekend project, it really doesn't matter at all. For a large, production application, there are real, important questions to answer and they matter a great deal. It's not "is a hammer good enough?" - A hammer is hardly good enough when you're staring at screws. I'm not saying one is right or one is wrong. I'm saying choosing a language is usually only something that matters at a certain scale, and at that scale, you have to be very knowledgable and careful.

jpgvm 12y ago
I wasn't saying someone should use Rust over Go because of Traits and other generic programming features. I was saying if you are evaluating Rust then Go probably looks very feature light in comparison. Same goes for programmers currently using Java/C# or even Haskell. Go is just a lot less featured than other high performance managed languages that are just as battle tested and just as fast. This is not to say that it's not a good language or the correct tool for a job. Only that those programmers will be left wanting in many areas, generics only being one.
- NateDad 12y ago
  People who use Java and C# actually have a lot fewer reasons not to use go. The lack of a required runtime applies to both, better cross platform compatibility then C#, and lower memory overhead and faster startup than Java... You lose generics but you gain real value types and better concurrency primitives.
- deleted 12y ago
  [deleted]

waps 12y ago

I can't believe how they're actually using "Built-in generic types, i.e. the current Go approach (generic types map/chan/slice)" as an argument AGAINST generics. I mean this is unbelievable. Of course that list is not complete, as there are more generic datatypes in Go (arrays, function return value-tuples, ...). Fact is, the golang authors are using generics (and polymorphism, and ...) in the language and in the compiler. So they have answered all the questions about generics : > does it result in a slow compiler ? Obviously not, after all the compiler has generics. > are generic structures less useful ? Well how useful do the Go authors find map/slice/arrays/... the generic Go datatypes ? So obviously this is both a bullshit argument and one people like Rob Pike don't actually believe is true. > Generic structures are less optimized If this is true, then clearly Go's authors find this an acceptable cost. More generally, let's take a look at Rob Pike's example code. For instance here is a talk described as "An hour-long talk delivered by Rob Pike at Google in October 2009. The language's first public introduction." http://talks.golang.org/2009/go_talk-20091030.pdf http://talks.golang.org/2009/go_talk-20091030.pdf First code example that isn't hello world, first function called : if len(str) > 0 { ch = str[0] } A polymorphic function ... weekend := []string{ "Saturday", "Sunday" } timeZones := map[string]TZ { "UTC":UTC, "EST":EST, "CST":CST, //... } Generic data types. Why are we arguing about this ? There is no disagreement between Go's users and authors : Go needs generics. The authors simply don't feel capable of implementing it. How about, like hundred other problems in Go we simply ask ourselves "is this hard to program in a compiler ?", and yes it is. So they put in an ugly hack for their own special cases. This argument, first of all, consistently fits all Go languge decisions leading to the correct conclusion, as opposed to all the arguments given by the Go authors that have no end of exceptions and personal preferences to take into account to arrive at the correct conclusion. Go's authors clearly have some trouble understanding the mathematical foundations of type systems, which is plainly visible in Go's type system. It's inconsistent. Without massive holes in the language, like we currently, this will become VERY visible and move people away from Go.

threeseed 12y ago
Shame you were downvoted as it definitely added to the conversation. That said I would disagree that flaws in a type system will result in people moving away from Go. Scala has a type system that is ridiculous complex and has plenty of holes and it doesn't seem to have affected its adoption rate.

wtf_is_up 12y ago

This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile time, language simplicity, toolchain simplicity, maintainability, etc etc For these developers Go can be a good fit. Everybody knows it doesn't have feature parity with Haskell et al from a computer science perspective. If that's all that mattered we would be seeing a lot of Haskell adoption wouldn't we? You shouldn't pick a language based on a checklist.

coldtea 12y ago
>This has been discussed ad nauseum but there exists a group of developers who value other language features, such as ease of deployment, readability, compile time, language simplicity, toolchain simplicity, maintainability, etc etc All of which are orthogonal to having a more modern language, except maybe simplicity. And even for that, after a while you understand that not having, say, generics, pattern matching or some such language feature, is not "simpler" is just having to do more busywork manually and in an error prone way. There's simplicity as in "this is simple to understand and use" and simplicity as in "we ommited some advanced functionality and you'll have to built it by yourself, every time". The second is a false simplicity. As Einstein put it: "we should make things as simple as possible, but not simpler". Pointing to a specific point were making something simpler makes it lose the essense it should have.
- NateDad 12y ago
  It is simpler. It's like comparing English to German. Sure, in German you can just say "schadenfreude" and in English you have to say "taking joy from someone else's misfortune", but everyone will understand the latter, and many people may misunderstand the former... And even though you may feel smarter for being able to use a big word, if you are writing a legal document that needs to be understood by many people, you're probably better off with the more wordy English.
  - coldtea 12y ago
    >but everyone will understand the latter, and many people may misunderstand the former... And the analogy breaks in that all German speakers will understand the former.