> 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.
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?
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. :/
>The selling point of go is that it is easy to read and maintain because it is so opinionated.
The selling point of Go for most people is rather: hey, a language with GC (easy to manage memory) AND nice parallel/concurrency story AND static builds AND faster than my dynamic language I use.
I don't think "it lacks generics" comes into play much as any kind of benefit.
That's a strawman: Grandparent said "easy to read and maintain" which is not "it lacks generics". The Go team has communicated that they would like to add generics if they could do it without breaking the language or introducing large inconsistencies.
Re the selling point: You're underestimating the importance of a conceptually simple language. If you put a new developer on a project in any other language that he has never used before, he will need at least a week to get up to speed. With Go, I had colleagues sending me pull requests with real, useful feature additions to my Go programs within 1-2 days of them installing the compiler.
>You're underestimating the importance of a conceptually simple language. If you put a new developer on a project in any other language that he has never used before, he will need at least a week to get up to speed. With Go, I had colleagues sending me pull requests with real, useful feature additions to my Go programs within 1-2 days of them installing the compiler.
Sure, but maybe you're overestimating the complexity of Generics (on the programmers, not the implementation of the compiler side)?
What makes you think those same programmers could not grok them? They could grok CSP (channels etc), implicit interfaces, pointers, reflection, unsafe pointer work, and closures, but suddenly Generics are too much? Seems rather arbitrary -- especially since the language already has generic functions.
It's also the matter of initial familiarity (productive in a few days) with eventual expressiveness and power (how much more productive in a few months and more)?
Because your argument seems to me like saying Go is Nano: one can start editing immediately.
Sure, but Vim/Emacs are worth the investment in learning them, even if one feels lost for a little while when starting with them.
Neither is there data for % of all programmers will move to Go if Generics are available.
> Choice is good.
It is even better by having more programing languages with preferred feature set.
> I don't understand people who hate generics.
Sure, just like you don't understand that, it is entirely possible some people who can write useful and robust production grade applications without generics to ask what is the big deal about with generics or lack of it.
> 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?
There is no need to decide on behalf of programmers on what concepts they should find difficult and what not. For example some people using Rust find borrow checker really difficult to grasp some find it an elegant and obvious way to track objects.
> % of all programmers will move to Go if Generics are available.
It's not about moving to Go, but about leaving Go. You can be pretty sure that there will be power users leaving the language unless it addresses many issues that it has. In fact, there are such people even here on HN already. It could, of course, end up being a language for non power users with the libraries of corresponding quality for awhile. And I feel like the quality issue is already here too. But ultimately not being an attractive choice for experienced programmers cannot be beneficial for the language in the long run.
> Neither is there data for % of all programmers will move to Go if Generics are available.
I never said that. It is you who used that kind of argument like there was any truth to it. There is none.
> Sure, just like you don't understand that(...)
I never said that. You keep on making stuff up.
> It is even better by having more programing languages with preferred feature set.
I don't think adding more programming languages to a project makes that project more maintainable and readable, it doesn't make sense. You're not going to convince me that juggling with multiple programming languages on a daily basis is "even better". It isn't.
> There is no need to decide on behalf of programmers on what concepts they should find difficult and what not. For example some people using Rust find borrow checker really difficult to grasp some find it an elegant and obvious way to track objects.
There is no need to decide that a feature you wouldn't even use yourself is bad either. Nobody would force you to use generics.
Yes and no. In a couple years, a Go developer gets hired at a shop and realizes on the first day "oh snap, these people have a years old codebase that uses generics everywhere and I'm stuck with it." Is he being forced to use them? Can he leave if he cares more about generics than his paycheck? Sure. Can you withold the combo to your safe from the home invader if you care more about what's inside it than your daughter he's pointing a gun at? Sure.
I don't think it's incomprehensible that GP prefers that a language remain simple and opinionated for the sake of what one might call "cross-developer" code.
Someone up the thread a ways mentioned 1980s C++, object oriented C++ and functional C++ as examples of how disjoint different styles of a single language can be when its building blocks allow it to be sufficiently flexible/agnostic. Another example that comes to mind is Lisp, where its ability to create macros and abstractions mean a developer can, if he chooses, essentially write his own language per project (as far as its legibility to newcomers is concerned).
C++and Lisp are both powerful, of course. But power isn't everything. Jira is much more customizable and flexible than Trello, but Trello is clearly doing quite well with the small subset of Jira features that a large chunk of the market is satisfied with.
Indeed, the whole "use only what you think is good" from a programming language is a fallacious argument. Or, at least, it only applies to the lone wolf developer who writes everything by him/herself.
Knuth fell into making this mistake in the 1993 Computer Literacy Bookshops interview, in which he responded thus on the topic of C:
DK: I think C has a lot of features that are very important. The way C handles pointers, for example, was a brilliant innovation; it solved a lot of problems that we had before in data structuring and made the programs look good afterwards. C isn't the perfect language, no language is, but I think it has a lot of virtues, and you can avoid the parts you don't like.
Yes, you can avoid the parts you don't like, if you're like Knuth, working on one program by yourself.
>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.
You're right, and the FAQ explicitly says that the designers aren't happy with the choice either.
If there would be a one time compile penalty for generics, it may work. The issue is that if large code-bases (Go's reason de'etre) will now take an hour to compile instead of five minutes, it's just dead in the water.
Also, it looks like they want to make Go a language where all code looks the same. So you won't find team A writing C++ like in 1980, team B writing C++ in OO mode, team C writing C++ in FP mode, etc.
It's so fanatical, that the spacing is standardized.
> The issue is that if large code-bases (Go's reason de'etre) will now take an hour to compile instead of five minutes
This is just FUD. Monomorphization takes a lot of time, but no one prevents the developer to keep the dynamic dispatch by default and just do the type-checking, this is not expensive. And for people who need more performances you add a compiler flag to perform monomorphization.
What you propose adds more complexity on top of generics. The Go team specifically does not want performance tweaks under flags as it adds complexity for no good reason.
If generics are to be added, they can't hurt performance and they can't hurt compile times noticeably. The tradeoff needed is too big to be worth it. If this is such a big problem to you, there are many languages out there that embrace the complexity and the tradeoffs. Scala or Kotlin might be good choices.
> The Go team specifically does not want performance tweaks under flags as it adds complexity for no good reason.
Giving the user the ability to balance his needs for compile-time or his needs for performance is not «complexity for no reason» imho. There is no complexity from the user's perspective, it's just "optimise" vs don't optimise and compile quickly, like what you have with C compilers. It's really different from other kind of performance tweaks, let say the choice between two garbage collectors with different trade-offs. Anyway I'm aware of the dogmatic stance of the Go team on the «simplicity» mantra …
> If generics are to be added, they can't hurt performance and they can't hurt compile times noticeably.
As I said, pure type-check generics with dynamic dispatch under the hood wouldn't hurt compile time and they wouldn't hurt performances because dynamic dispatch is exactly what Go already does with interfaces.
> If this is such a big problem to you, there are many languages out there that embrace the complexity and the tradeoffs. Scala or Kotlin might be good choices.
Not everybody is responsible for the technical environment he is working in. And I'm not sure that telling «if you're unhappy then GTFO» somebody who says he has a problem with the language is a really good approach.
> 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.
1. Sometimes being able to ship is more important than being perfect
2. Sometimes I don'tcare if it's perfect. If I need something for in-house use, Go (and Python) is quite enough for my needs.
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.