6 ms·

With the significant risk of becoming less interesting for large number of current users.

by geodel 10y ago

Dobbs 10y ago
As a daily user of Go, I wish so much it had some tools in its toolbox for simple boxed generics. Things like `Stack<T>(a T)`, `Max<T>(a T, b T)`, and other data structures and basic functions. Then for `err == nil` we need some type of syntactic sugar to simplify this. I don't know what it would look like, but so many copies of that simple if statement get written that it is a bit ridiculous.
- geodel 10y ago
  My experience working with Java all these years is this: 1) Java is not suitable at all the task at hand. I am just trying to solve something far more suitable for different type of language. 2) Java is working fine for the purpose and it leaves me with time to think how about Java fix its longstanding issues. Ideally Java should fix that stuff but I come to conclusion 2) is possible only when Java works fine for me and fixing those issues is either impossible or very low priority. I think same will apply to Go or any other language.
camus2 10y ago
> With the significant risk of becoming less interesting for large number of current users. There is no data demonstrating that statement. I don't think you are talking for the majority of people using Go. Choice is good. Generics in the language wouldn't change anything for you as you wouldn't be forced to use them. I don't understand people who hate generics. They are just types and they are here to help the developer write compile time type safe code. interface {} everywhere isn't compile time type safe. The biggest argument against generics, is that it would increase compilation times. Well, the compiler would be still faster than the developer copying and pasting code manually, or rewriting the same algorithm for each type variation again and again. Isn't programming about automating stuff? For those who complain generics are too complicated to understand, I don't know what kind of developer you are frankly if you can't understand something as basic as generics yet pretend like you can work with a language that has pointers,channels and threads and mutexes... What do you think is more complicated? generics or concurrency? While the argument itself is pointless (it's unlikely one can retrofit generics in a backward compatible way with Go), there is no need to answer with these bad faith arguments. It really sound stupid.
- wyager 10y ago
  > They are just types and they are here to help the developer write compile time type safe code. Type safety mostly appeals to developers with a low time preference. Getting a bunch of compiler errors is the opposite of immediate gratification. In a language like python, you can start running your program instantly and push dealing with bugs as far back as possible. You might spend more time, since debugging is harder and slower in the long run than making the compiler catch mistakes up front, but you get to procrastinate.
  - junk_disposal 10y ago
    1. Sometimes being able to ship is more important than being perfect 2. Sometimes I don't care if it's perfect. If I need something for in-house use, Go (and Python) is quite enough for my needs.
  - dpc_pw 10y ago
    > In a language like python, you can start running your program instantly and push dealing with bugs as far back as possible. Which is often never. Part of the reason why I avoid using anything written in Python.
- andmarios 10y ago
  The selling point of go is that it is easy to read and maintain because it is so opinionated. If you start adding features that only some programmers use, then you lose the language's strongest point. For Go choice is bad. Go is going so strong because any Go programmer can read any Go program and library after a couple days with the language. Can you say the same for any language that has generics?
  - weberc2 10y ago
    I agree with this, but at the same time some solution for type safe generic data structures would be nice. I'm not sure if there is a best-of-both-worlds solution. :/
  - coldtea 10y ago
coldtea 10y ago
Considering that C#, Java and C++ (which have those features) have 10x or more users than Go, that sounds like a good risk to take.
- majewsky 10y ago
  That's the same fallacy as the Twitter board trying to turn Twitter into Facebook. Sure, if Twitter were Facebook, it would have more users, but no-one needs a second Facebook.
  - coldtea 10y ago
    That would be the same fallacy is there was only one other such language I could mention. But between C#, Java, C++ and tons of others, it seems people do need "second" and "third" such languages...
- gribbly 10y ago
  Oh come on, those languages have been around for 20-30 years, Go has been around for 7 years and haven't seen anywhere near the push from Google that C# and Java had from Microsoft and Sun. And it's not as if generics is off the table, personally I think they will arrive eventually, here's what Go lead Russ Cox said in January this year: https://research.swtch.com/go2017#generics https://research.swtch.com/go2017#generics

With the significant risk of becoming less interesting for large number of current users.

by geodel 10y ago

With the significant risk of becoming less interesting for large number of current users.

Dobbs 10y ago

As a daily user of Go, I wish so much it had some tools in its toolbox for simple boxed generics. Things like `Stack<T>(a T)`, `Max<T>(a T, b T)`, and other data structures and basic functions. Then for `err == nil` we need some type of syntactic sugar to simplify this. I don't know what it would look like, but so many copies of that simple if statement get written that it is a bit ridiculous.

geodel 10y ago
My experience working with Java all these years is this: 1) Java is not suitable at all the task at hand. I am just trying to solve something far more suitable for different type of language. 2) Java is working fine for the purpose and it leaves me with time to think how about Java fix its longstanding issues. Ideally Java should fix that stuff but I come to conclusion 2) is possible only when Java works fine for me and fixing those issues is either impossible or very low priority. I think same will apply to Go or any other language.

camus2 10y ago

> With the significant risk of becoming less interesting for large number of current users. There is no data demonstrating that statement. I don't think you are talking for the majority of people using Go. Choice is good. Generics in the language wouldn't change anything for you as you wouldn't be forced to use them. I don't understand people who hate generics. They are just types and they are here to help the developer write compile time type safe code. interface {} everywhere isn't compile time type safe. The biggest argument against generics, is that it would increase compilation times. Well, the compiler would be still faster than the developer copying and pasting code manually, or rewriting the same algorithm for each type variation again and again. Isn't programming about automating stuff? For those who complain generics are too complicated to understand, I don't know what kind of developer you are frankly if you can't understand something as basic as generics yet pretend like you can work with a language that has pointers,channels and threads and mutexes... What do you think is more complicated? generics or concurrency? While the argument itself is pointless (it's unlikely one can retrofit generics in a backward compatible way with Go), there is no need to answer with these bad faith arguments. It really sound stupid.

wyager 10y ago
> They are just types and they are here to help the developer write compile time type safe code. Type safety mostly appeals to developers with a low time preference. Getting a bunch of compiler errors is the opposite of immediate gratification. In a language like python, you can start running your program instantly and push dealing with bugs as far back as possible. You might spend more time, since debugging is harder and slower in the long run than making the compiler catch mistakes up front, but you get to procrastinate.
- junk_disposal 10y ago
  1. Sometimes being able to ship is more important than being perfect 2. Sometimes I don't care if it's perfect. If I need something for in-house use, Go (and Python) is quite enough for my needs.
- dpc_pw 10y ago
  > In a language like python, you can start running your program instantly and push dealing with bugs as far back as possible. Which is often never. Part of the reason why I avoid using anything written in Python.
andmarios 10y ago
The selling point of go is that it is easy to read and maintain because it is so opinionated. If you start adding features that only some programmers use, then you lose the language's strongest point. For Go choice is bad. Go is going so strong because any Go programmer can read any Go program and library after a couple days with the language. Can you say the same for any language that has generics?
- weberc2 10y ago
  I agree with this, but at the same time some solution for type safe generic data structures would be nice. I'm not sure if there is a best-of-both-worlds solution. :/
- coldtea 10y ago

coldtea 10y ago

Considering that C#, Java and C++ (which have those features) have 10x or more users than Go, that sounds like a good risk to take.

majewsky 10y ago
That's the same fallacy as the Twitter board trying to turn Twitter into Facebook. Sure, if Twitter were Facebook, it would have more users, but no-one needs a second Facebook.
- coldtea 10y ago
  That would be the same fallacy is there was only one other such language I could mention. But between C#, Java, C++ and tons of others, it seems people do need "second" and "third" such languages...
gribbly 10y ago
Oh come on, those languages have been around for 20-30 years, Go has been around for 7 years and haven't seen anywhere near the push from Google that C# and Java had from Microsoft and Sun. And it's not as if generics is off the table, personally I think they will arrive eventually, here's what Go lead Russ Cox said in January this year: https://research.swtch.com/go2017#generics https://research.swtch.com/go2017#generics