Earlier quoted context omitted.
Dinamic languages don't need generics
Can you explain?
In dynamic languages the type is known at runtime.
Proposal: Go should have generics
231–240 of 439 posts
Re: Proposal: Go should have generics
#232At this point, I have to just conclude that Go isn't "for me". I respect the great things the community has produced. But I'm just not interested in a static language without generics.
Re: Proposal: Go should have generics
#233As long as programmers that are comfortable with (and prefer) 30+/40+ year old PL paradigms are at the helm of Go's design, it's not very likely the language will grow Generics. To paraphrase Max Plank: "A new language-level feature does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it."
Only Max Planck was talking about questions of truth.
That's why I said I'm paraphrasing him.
That said, he talked about questions of physics, not "truth".
Now, those new theories might or might not be truth.
But the fact that (in his phrasing) they only prevail not because of extra proof, convincing etc., but just because a generation that didn't like them died, doesn't make them seem particularly "truth" based.
Mostly "generational-fashion" based.
It could of course be that the new generation of physicists is also more capable to accept the truth (and Plank might believed that), but this doesn't derive directly from the statement.
The statement only goes as far to say that new generations of physicists are more capable to accept newer theories (the ones that grew with them, and they are more familiar with them than the oldsters are).
Re: Proposal: Go should have generics
#234Isn't a huge issue with generics the compilation time? Much as I love Haskell, I'm not going to sit here and tell you that a big program compiles quickly. That might be an individual issue with Haskell, but regardless, isn't type-inference kind of expensive in compilation-land? And wouldn't that kind of kill one of the big features of Go?
Type inference isn't synonymous with generics, and it isn't necessarily expensive. It depends exactly how much you leave up to the compiler.
Some very strong kind of type inference are undecidable in general and can be very expensive to compute when there is an answer.
But you might bear in mind that almost all static compilers, including Go, already determine the types of arguments to functions so they can complain if you're passing the wrong type. Comparing that against a set of functions isn't much of a stretch, especially if the type matching rules were pretty strict, as they normally are in Go.
Not all generics are generic functions, anyway. A more limited, but still potentially useful, form of generics is generic packages. Generic packages have type parameters, whilst inside the package refer to the specific concrete type the package is being instantiated for.
A hypothetical sort package might have a single parameter denoting the element type it sorts. Conceivably it could be defined as
package sort(T)
func Sort (a []T) ...
import isort "generic/sort" (int)
Re: Proposal: Go should have generics
#235Isn't a huge issue with generics the compilation time? Much as I love Haskell, I'm not going to sit here and tell you that a big program compiles quickly. That might be an individual issue with Haskell, but regardless, isn't type-inference kind of expensive in compilation-land? And wouldn't that kind of kill one of the big features of Go?
I don't think generics necessarily compile particularly slowly.
Re: Proposal: Go should have generics
#236can I tell u the BEST thing about golang? Strings cannot be nil! It's amazing. They are always "" or you know, "something" so you never have to test for if s == nil || s == "" or in ruby s.blank? to cover both cases. that is all.
Are you being sarcastic? That's a good thing.
Re: Proposal: Go should have generics
#237Earlier quoted context omitted.
> you are not "sorting" new kind of "types" every day You'd be surprised.
I am writing a chemoinformatics database, so for my practical use, these are a lot of lines of codes with pretty involved algorithms and I am practically not annoyed by the lack of generics. For the ones down-voting me, have you coded something in Go, big enough to be a real in production project, where at the end the lack of generics is a real issue (performance because using interfaces or maintenance because copy/p…
I'm part of a project team that uses quite a lot of Go in production (for analytics work), and lack of generics was particularly painful.
>(performance because using interfaces or maintenance because copy/paste to have the performance)?
I don't like interfaces (namely, interface{}) for their lack of safety for generic work -- performance comes second to that.
And I don't like copy/paste like ever.
>For the ones down-voting me, have you coded something in Go, big enough to be a real in production project, where at the end the lack of generics is a real issue (performance because using interfaces or maintenance because copy/paste to have the performance)?
Isn't that a sure fire way to selection bias? The ones that ended up coding something significant in Go will usually be those that put up with the Generics issue (or don't even know what they are missing).
It's like asking C programmers if they mind missing GC, closures, etc.
It's not like the utility of Generics is some open question in PL either. It's a settled matter. Even Go uses them, but doesn't offer them to the programmer, or suggests generic but not type-safe solutions like interface{}.
Re: Proposal: Go should have generics
#238The one thing that makes Go special is that it's pure "Engineering-Zen". While that doesn't make programming in Go the most fun exercise it makes it a profound one (after some getting used to). Less distractions, less eGo (forgive the pun). Disclaimer: I'm still having a hard time embracing all of that myself - I don't even like Go. I really miss all the functional cleverness I've come to get used to over the years -…
How do you cope?
Weirdly enough I started my career writing selenium test in clojure and got used to (reduce (map (filter ... way of doing things.
Then we moved to python and still I was at least able to do (modified(x) for x in xs where satisfies(x))
Then I needed to do some C# work and I really liked LINQ.
Now I work in javascript and still can at least _.chain(thing).map().filter().value()
It seems that we will use Go for some things, and as far as I know, I am back to using for cycles.
Re: Proposal: Go should have generics
#239Earlier quoted context omitted.
Go doesn't do inheritance either. It has type embedding, but it's not the same. In the most recent of Ian Lance Taylor's proposals (Type parameters, 2013 [1]) he summarizes: > The implementation description is interesting but very complicated. Is any compiler really going to implement all that? It seems likely that any initial implementation would just use macro expansion, and unclear whether it would ever move beyon…
> Go doesn't do inheritance either. It has type embedding, but it's not the same. It does have interfaces though.
This is generally brought up as the reason that Go doesn't need generics.
I tend to agree with this. I've yet to come across a use-case where the current system is too difficult to deal with, but there are other people who have hit this limitation.
Maybe this can be solved by simply modifying the parsing of the keyword "type" (Or adding a reserved type "T") and telling developers that the functionality of "go generate" will automatically (in the compiler) expand and create type methods at compile time, and build the type generation into the compile phase, rather than a manual pre-compilation phase. I haven't considered the problems with this approach, but I assume Ian et al have.
It seems to me that the generated code approach could be spliced into the compiler with a few key-word parsing changes, but I'm not going to assume that the Go team haven't already thought of this, and there are probably problems with the idea that I haven't considered, above and beyond spec / compatibility promises etc.
Re: Proposal: Go should have generics
#240Isn't a huge issue with generics the compilation time? Much as I love Haskell, I'm not going to sit here and tell you that a big program compiles quickly. That might be an individual issue with Haskell, but regardless, isn't type-inference kind of expensive in compilation-land? And wouldn't that kind of kill one of the big features of Go?
Type inference isn't synonymous with generics, and it isn't necessarily expensive. It depends exactly how much you leave up to the compiler. Some very strong kind of type inference are undecidable in general and can be very expensive to compute when there is an answer. But you might bear in mind that almost all static compilers, including Go, already determine the types of arguments to functions so they can complain…
Admittedly I've never implemented a compiler, or a type system, so I was just speaking out of my behind to an extent, but your explanation makes sense.