25 ms·
Proposal: Go should have generics
- f2f 10y ago"The intent is not to add generics to Go at this time, but rather to show people what a complete proposal would look like. We hope this will be of help to anyone proposing similar language changes in the future." This started in 2010. Hopefully an illustration that go's developers are not against generics in general, this ought to quell some of the negativity... Pick one of the four proposals you like :)
- andrewstuart2 10y agoThe proposal document itself may have existed for that long, but it's only been public for 14 days. To me, the important portion is the link to the discussion issue [1] created 2 hours ago, which to me seems like a more significant step towards doing the actual work. Before, the default response was "we're thinking about it." Now, it's "let's all talk about it." [1] https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292
- f2f 10y agobut the existence of the proposals assumes there were internal discussions, which is counter to the argument that go devs don't care about generics. had anything good come out of that it would've been published in the open. as it stands, the negatives outweigh the positives. hopefully the new discussion will change that, or an entirely new proposal will make everyone see the light.
- kyrra 10y agoThis was actually mentioned during the Golang team's AMA on reddit. They have wanted to make the proposals for generics public for a while, it probably just took some effort to organize it all and make sure it was OK to publish. https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d03tsxw https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t... > Some people on the Go team have sunk considerable time in producing generics proposals, but they've all had serious drawbacks. I'm hoping those proposals will be published at some point so people can see the depth of complexity that generics bring; it's almost always underestimated.
- deleted 10y ago[deleted]
- dsymonds 10y agoIt's not so much "let's all talk about it", but "here's how detailed a proposal needs to be to make it worth considering".
- andrewstuart2 10y agoSorry, I mean the opening of a Github issue regarding generic programming by the Go team itself is the beginning of a new stance.
- dsymonds 10y agoIt isn't a new stance either. For years people have been posting their ideas for Go generics to golang-nuts, and the questions inevitably lead to asking how they'd implement it, how it would interact with interfaces, and so on. Most of the time the proposer hadn't thought it all the way through in those regards. The point of publishing these proposals is to help speed up that process: now the first response can be to point at these and ask for a similar level of thoroughness.
- deleted 10y ago[deleted]
- Scarbutt 10y agoThey better implement something very near by, Swift is coming for them.
- drivebyops 10y agoYea Swift is honestly great to write
- eyko 10y agoDoesn't Swift's tooling leave much to be desired?
- zimpenfish 10y agoI haven't really looked at Swift properly but from what I see on the iOS dev blogs I follow, it's a lot more complex than Go and I can't see how productivity / etc. would be improved sufficiently to make the learning and general brain investment worthwhile for me.
- coldtea 10y ago>This started in 2010. Hopefully an illustration that go's developers are not against generics in general, this ought to quell some of the negativity... Wouldn't the fact that this started 6 years ago and gone nowhere re-enforce the negativity?
- xiaopingguo 10y agoWhy not just fork the language? Why does one language need to do all the things?
- duaneb 10y agoGenerics are not "all the things". Last i checked there was still no object inheritance (in a subtype sense for interface implementations), no operator overloading, no bytecode/vm/jit, no inline asm, no macros, no pluggable gc, no call/cc, no (idiomatic) exceptions, no currying, no weak typing or implicit conversions, no way of enforcing referential transparency, no STM, no laziness, no assertions, no contracts, no untagged unions, no algebraic data types, no covariant return types, no pattern matching, no method overloading, no simd, no decorations/annotations.... I am sure i missed a lot. EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala.
- ViktorasM 10y agobut having all those things go would become another C++ with a different syntax. I like the direction Go is going of "there are no options to choose", like unconfigurable fmt, or the fact that there is no way to create "exotic" implementations. However, generics would be my number #1 on the list of "maybe let's add that". Would be nice to have less "interface {}" in reusable libraries. Exceptions would be probably second, but that would come with some sort of runtime cost. With them Go would start to drift towards "generic programming language".
- pcwalton 10y agoExceptions don't have any runtime costs beyond those which Go is already paying by mandating unwinding. In fact, C++-style exceptions are strictly less expensive in the non-exceptional case than defer, because of defer's dynamic semantics. Go's semantics require a slower exceptional control flow scheme than almost any other language I'm aware of, including dynamic ones like JavaScript.
- 10y ago
- bigdubs 10y agoAfter watching Rob Pike's Go Proverbs talk I am pretty convinced generics, as much as some would want it, will never happen. He proselytizes "just copy a little code here and there" quite clearly, which is at odds with the complexity that generics would add.
- ktamura 10y agoThis. For better and for worse, Go was designed for "simplicity", and generics are anything but simple. I'd be very, very surprised if Go thinks about generics in earnest anytime soon. I don't say this in anyway to eulogize Go: In some ways, Go is pathetically unexpressive. That said, it currently fills that gap for writing middleware between C sacrificing too much developer productivity and Perl/Python/Ruby/PHP sacrificing too much performance. Generics would be nice to have for this core use case for Go, but it's probably not critical.
- slantedview 10y agoGenerics can be (relatively) simple - see C#, they just tend not to be in many implementations.
- bigdubs 10y agoCLR (the C# runtime) generics are fully reified and about the most complicated and robust implementation available. It dynamically emits and loads types whenever a new generic parameter is seen for a function or type. This is very, very hard to get right and is not very performant. It also puts a lot of burden on the runtime vs. the compiler. Go expressly tries to keep the runtime as small as possible.
- pcwalton 10y agoCLR-style just-in-time monomorphization is plenty performant: in fact, it's just about ideal. It's also not that difficult when you have a JIT when compared to the complexity you need for speculative optimizations of hot spots anyway. In any case, the .NET approach isn't an option for AOT compilers like those of Go. For Go, the only reasonable option is ahead of time monomorphization, which really isn't that bad.
- willvarfar 10y agoI would be happy if there was a generics solution aimed just at type-safety for containers, and not a general 'reuuse' thing.
- Ericson2314 10y agoYou can easily have type parameters in data type definitions but not expressions, but that wouldn't by much for containers.
- slantedview 10y agoFrom the post: > As Russ pointed out, generics are a trade off between programmer time, compilation time, and execution time This misses the most important metric: quality. Lack of generics forces copying and pasting of code which inevitably lowers quality and increases defects. It's amazing to me that with the all the expense that crappy software causes, we're more focused on compilation and execution time. Last time I checked Golang's performance numbers, the supposed benefits of this focus were not present while the downsides of being a language that forces programmers to do the wrong thing were present as well.
- deleted 10y ago[deleted]
- Gibbon1 10y agoI often get crap when I mention most of the time execution speed is just not important. However it is important vastly more important for google than me or you. Simply because google and a lot of other web companies are running on such tight margins. Consider my company is paying maybe $200/mo for AWS. When we are doing half a million a month in business. Each cpu cycle for us represents a lot more revenue for us than google is making. The flip side is programmer time matters a lot more to you and me than to google.
- thegenius2000 10y agoI agree with the author's request, I'm just not convinced he proposes a design. I mean I recognize see the need for some sort of generic programming, but the big question is how not why, right? Edit: My bad. Didn't see the bottom of the page.
- wrs 10y agoHe's proposed four designs so far. See the bottom of the page.
- peteretep 10y agoIf they accept generics, then there is an implication that the language design isn't infallible as a result of being written by Rob Pike, and then the whole house of cards falls down as people start clamouring for things like real exceptions.
- enneff 10y agoYour comment does a great disservice to Robert Griesemer, Ken Thompson, and the many others who contributed to Go's design.
- nostrademons 10y agoNot to mention Ian Lance Taylor, who's been on the Go team since before it was public, authored the GCC Go frontend, was de-facto leading the team when I left Google in 2014, and also happens to be the author of the proposal.
- Ericson2314 10y agoYeah they haven't done it yet, and might still never do it, to save face. What could have been a simple 1.0 missing feature has been politicized into Go's defining feature/mistake.
- enneff 10y agoThere is nothing political about it, and speaking as someone on the inside it is simply ridiculous to think of it that way. What these real proposals show is that a lot of sincere effort has been spent by members of the core team writing, reviewing, and debating generics proposals over a span of multiple years. Ian only recently felt comfortable releasing them publicly, and so here they are.
- Ericson2314 10y agoI don't want to start a flame war, but parametric polymorphism has been exhaustively studied for decades. Any technical difficulties of bolting it on Go at this stage probably stem from uncertainty about Go's existing semantics rather than the new feature itself. So I hope there are non-technical reasons that have led to the features delay.
- elcct 10y agoOne day someone will create a fork and implement it.
- Animats 10y agoGenerics as a language retrofit tend to be ugly. See C++. I was at one time plugging for parameterized types. Go already has parameterized types; "map" and "chan" are parameterized types. You write "make(chan int)" and "make(map[string] int)". You just can't define new parameterized types; "map" and "chan" are all you get. With parameterized types, you could create more generic data structures; if you needed a generic b-tree or a quadtree library, you could have one. Maps in Go are more special than they should be. Parameterized types are less powerful than generics, but not too far from what Go now has. The goals in the document mentioned here require generics with all the bells and whistles. Remember, Go still has reflection; if you don't need high performance, you can simulate generics at runtime.
- Ericson2314 10y agoReflection comes without the compile time guarantees (parametric polymorphism offers), and that is a far greater loss than the missed performance opportunities.
- eva1984 10y agoBut it is useful, and offer you compile time checking. The current interface{} workaround doesn't quite solve the same problem, rather it is like a bad excuse.
- rdsubhas 10y agoDepends on the implementation. See Java.
- robwilliams 10y agoC# generics work beautifully and they were retrofitted. Later language additions like LINQ and extensions take advantage of generics as well.
- mk44 10y agoGo is designed by google, for google. Why should they make it to your liking? Why do you rely on google?
- mattlondon 10y agoI can feel the pain on the Sort issue. I've personally found sorting annoying in Go - I had a bunch of structs representing data entities from a database that all had the same field and I wanted to be able to sort them by this field. Seemed like a LOT of work (basically implementing the same sort that was 99% identical for every struct) or use weird reflection-workarounds to get this to happen. In Java I would not even given this a second thought and be back to coding up the important part of the code ages ago. I am a new go-lang user so would love to know what the best approach to resolve this is without a) repeating the same thing for every struct, or b) relying on "unsafe" reflect techniques (since AppEngine rejects code that does that) - surely sorting structs is a super-common, basic thing for a systems language? I've seen someone just nonchalantly say "Use interfaces" but I'm not sure still. I like the language generally but this is a real "WTF?" moment for me.
- xiaq 10y agoWrite a code generator. That's the best solution at this moment.
- enneff 10y agoOr, y'know, just copy and paste the trivial code. It should take all of 30 seconds. Not saying that it's pretty, but it's quick and easy.
- junke 10y agoAnd that's exactly why I am not convinced that Go is as maintainable as often claimed. 30 seconds for you, but how many hours for the poor souls who will come after you and ask: should I change this copy too or is it a separate case? It reminds me of this: http://typicalprogrammer.com/abject-oriented/ http://typicalprogrammer.com/abject-oriented/
- enneff 10y agoThis thread is about sort interface implementations. Their general form will never change, and the only specifics unique to any given copy are those specific to their type. It is obvious to any Go programmer what can and cannot be changed in this situation.
- deleted 10y ago[deleted]
- isuckatcoding 10y agoThis makes me wonder if this has happened before in another language. I can totally imagine 10 years ago someone saying "oh we'll never need that in PHP" and voila 10 years later you've now got feature X in PHP. Any of you wise old timers want to share such examples? Does history keep repeating itself with these sorts of things?
- kqr 10y agoGenerics in Java? Anonymous functions in Java? Most everything in Java?
- isuckatcoding 10y agoI guess I was think of the community mentality and how it evolves as well.
- TazeTSchnitzel 10y agoPHP now has optional strict type checking for non-complex types, since last year. That was a huge change: https://ajf.me/talks/2015-10-03-better-late-than-never-scalar-type-hints-in-php-7 https://ajf.me/talks/2015-10-03-better-late-than-never-scala...
- teps 10y agoWhat people think of generic package instead of fine grained generics? https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.wko1dvdznk4y https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX... I think they would really fit the language well. The good part is: * Only the package and import statement change, the rest of your code stay the same and is not cluttered * They are easier to reason about as it is more coarse grained * They do not break the compatibility The the bad part is: * You cannot implement filter/map/reduce (but being able to implement them would conflict with the orthogonality of the language) * It could lead to code bloat, but not more than manually copy pasting the code.
- stcredzero 10y agoI like this idea. It would allay a lot of complaining.
- dom96 10y agoMaybe instead of adding generics to Go it's time to look into alternative programming languages which already implement generics, like for example Nim.
- idobai 10y agoYou forgot that most of golangers are ex-php programmers and students with no experience. Just look at what they're talking about: they think generics are the opposite of simplicity and can make performance and compilation time worse. Meanwhile, Nim has generics with other useful features and has faster compilation time along with better optimization. If google would put 'goto' into go golangers would still use it anyway. I've tried go a few times and it was full with repetition and boilerplate - felt like java 1.0. It seems like new coders like to repeat themselves more often than learn how to use proven concepts.
- Rooki 10y agoGo does have 'goto'. https://golang.org/ref/spec#Goto_statements https://golang.org/ref/spec#Goto_statements
- treehau5 10y ago> You forgot that most of golangers are ex-php programmers and students with no experience. How hopelessly smug and incorrect.
- idobai 10y agoJust look at the "conversion" blogs, most of the writers are php and python devs. And if you look closer you'll see that most of these bloggers are around 20 and they don't tolerate such complex things like generics...
- serge2k 10y agoIt's a conversation about go, isn't being smug and/or incorrect fundamental to participating?
- 10y ago
- ngrilly 10y agoThe four proposals linked at the bottom of the page are very interesting, and prove that a lot of work have already been invested in bringing generics to Go. It makes me confident that it will happen one day, when the pieces fit together in a nice way.
- max_ 10y agojust fork the repo.
- coldtea 10y agoAs 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."
- fauigerzigerk 10y agoOnly Max Planck was talking about questions of truth.
- elmigranto 10y ago> To paraphrase Max Plank
- coldtea 10y agoThat'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).
- fauigerzigerk 10y ago>That's why I said I'm paraphrasing him. I suppose you paraphrased him to draw an analogy. And you did it by replacing "scientific truth" by "language level feature". >That said, he talked about questions of physics, not "truth" Here's what he said: A scientific truth 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. Similarily, proponents of generics like to portray the creators of Go as the old guard that is in denial of an indisputable scientific truth. But whether or not the added expressivity of generics is worth the added complexity they introduce into a language is a matter for debate dependent on context, not a settled scientifc question.
- sambeau 10y agoIf it was up to me I would break with ASCII for the syntax. It would make parsing easier for the compiler while simultaneously making it slightly annoying to use for the programmer. Having to reach for a complex key combination would be enough to remind everyone that Generics should be used sparingly.
- amelius 10y agoHow does Erlang solve it?
- pmarin 10y agoDinamic languages don't need generics
- brndn 10y agoCan you explain?
- pmarin 10y agoIn dynamic languages the type is known at runtime.
- nostrademons 10y agoThe point of generics is so that you can use the same code with many different types. With dynamic typing, you can use the same code with anything, it just complains at runtime if you call an operation that isn't supported on a particular type. It's like every operation is implicitly generic. You could look at generics as a way to bring some of the flexibility of dynamic languages to a static type system, so you get the expressivity benefits without sacrificing type-safety.
- golergka 10y agoLack of generics was one of the reasons I abandoned Go halfway through a hobby project (the other reason was lack of normal exceptions). But. Go's principle is simplicity and understanding the concepts you're working with. And generics as a concept is a little bit more complex than simple List<int> explanation leads you believe. As C# developer (language with very good generics support), most of other C# developers I've met, unfortunately, can not easily and confidently explain covariance and contravariance concepts in an interview setting — which means that they don't understand generics concept completely. Mix it up with "null" virtual type, and you've got yourself a type system that you think you understand, but really don't, and will discover this misunderstanding in the worst possible moment. So, while Go sucks for projects that I personally usually work on, its qualities make it a great language for other kinds of projects, and for these projects, generics may not be wort it with a trade off with simplicity.
- dschiptsov 10y agoGo is supposed to be a better C, not a better C++.
- loup-vaillant 10y agoA "better C" with garbage collection by default? C and Go are in different categories. They fill different niches.
- dschiptsov 10y agoThe main designers of Go (originally from Bell Labs) might think otherwise.
- dllthomas 10y agoWhy couldn't a better C have generics?
- musha68k 10y agoThe 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 - especially talking Erlang/OTP as the main (losing) "competitor" for most of my backend projects here (microservices, kubernetes yaddayadda).
- a-saleh 10y agoHow 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.
- musha68k 10y agoHi there, I feel you :) The way I've coped with this so far is to embrace it and just work through the given task - less warm-fuzzy-feeling and more "manual work" and time needed for sure but it wasn't that big a deal once I just let "go"... Not having list comprehensions definitely is one of those things which makes me feel more like a "stupid coding monkey" but again you can be productive with less elegant tooling as well...
- a-saleh 10y agoWell, we shall see how this will end up :) If everything we would do are just simple micro-services, I think I would actually kind-of enjoy it.
- jgalt212 10y agoAs an outsider, I've been following Go for a while, and given the lack of common high productive language features such as Generics and optional function arguments with default values, to me, it seems like right now Go is much better than C, and in some dimensions better than Java and in others worse. If it just adds a few things, and then when you account for portability and speed, it could be better than the dynamic languages that people often compare it to.
- andrewfromx 10y agocan 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.
- kdogt 10y agoIn sane languages (see: Haskell, Swift, Rust), this is the case for all types. Having non-nullability only be the case for one type might be worse than having everything nullable, actually.
- Ono-Sendai 10y agoAre you being sarcastic? That's a good thing.
- meapix 10y agoCan you give an example of the issue you're trying to solve with Generics and Go is giving you hard time? don't take Go to C++.
- tombert 10y agoIsn'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?
- wcummings 10y agoWho said anything about type inference?
- parenthephobia 10y agoType 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) ... imported as import isort "generic/sort" (int) and then used as isort.Sort.
- tombert 10y agoAdmittedly 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.
- Ono-Sendai 10y agoI don't think generics necessarily compile particularly slowly.
- agentgt 10y agoI have some biased doubts (come from the JVM world) about needing really fast compiling and is often cited as the reason Go does things the way it does (or is). Is binary dependency management just not an option ever? I have a friend that works for Google and supposedly they have a proprietary build infrastructure that will offload the building of C++ code into a cluster. I sort of wish Google open sourced that as I believe it basically does some form of binary dependency management. Yes I know Go like C++ can target lots of platform (and thus needs many binaries built) but an organization only needs the major ones. And yes I know the language statically compiles to a single binary but that doesn't mean things can't be precompiled. Go these days seems to be mainly used for microservices or small utilities and thus you don't need and should not have a gigantic code base for such things. I can understand monolithic UI apps having large code bases but this is clearly not what Go is being used for these days. There are many other languages that compile to native that seem to compile fairly fast (OCaml and Rust from my experience but I don't have huge code bases). Is compilation speed really an issue given the use cases for Go?
- mikecb 10y agoThe G build system was open sourced: http://bazel.io/ http://bazel.io/
- serge2k 10y agoNot the distributed secret sauce though. > Does Bazel require a build cluster? Google's in-house flavor of Bazel does use build clusters, so Bazel does have hooks in the code base to plug in a remote build cache or a remote execution system. The open source Bazel code runs build operations locally. We believe that this is fast enough for most of our users.
- mikecb 10y agoUnless you have a very advanced infrastructure sitting around, their version of the distributed pieces is going to be worthless. Same reason tensorflow was initially released without it.
- 10y ago
- acjohnson55 10y agoAt 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.
- insulanian 10y agoMy code is full of map, filter, reduce/fold and similar generic reusable functions. How do people deal with such things in Go? Do they really make copies of such functions for every type they're working with? (And by type I don't mean just int/string, but all model entities/classes.)
- NateDad 10y agomap and filter are often just syntactic sugar for a loop, so I just write a loop. I work on a ~1M LOC codebase in Go and it's really not a problem. map and filter would not make my life significantly easier. They're solving easy problems. Sure, I have some of this style code: var names []string for _, m := range machines { names = append(names, m.Name) } But, really, is that so much worse than this? names = [m.Name for m in machines] Sure, it's spread across a few more lines, but line returns don't cost extra money... and if you decide you want to later do something more inside the loop for each machine (default the name, cache the ID, etc), you can do that trivially by adding lines inside the loop. This code is not hard code to write. If you're used to just being able to slap out map/filter etc in a single line, I could see how it could be annoying... but it's easy, just write it. There are far more difficult things to figure out in our jobs, why worry about the easy stuff?
- dominotw 10y ago>> But, really, is that so much worse than this? names = [m.Name for m in machines] You can take that code and interpret that as database query, like C# LINQ. you frist example is 'how' vs 'what' of second example. Once you stop telling the computer how to do things and just tell it what you want all kinds of things become possible.
- NateDad 10y agoBut then you have no idea what the computer is actually doing. There's a big performance difference between an in-memory loop and querying a database. This is one of the things I like about Go... what the computer actually does in response to any random line of code is pretty obvious (except for function calls, which of course can do anything). When you hide away the loop inside a map statement, you get people doing dumb things like this: names = [m.Name for m in machines] ids = [m.ID for m in machines] addrs = [m.Address for m in machines] So now we're iterating of over the list of machines 3 times... or making 3 database queries or whatever.
- chmike 10y agoConsider using the D language instead if generics is a problem. Go is what it is and shouldn't change. It has it's advantages that make it optimal for particular contexts. Otherwise you'll turn it into another c++. There is a strong benefit in keeping Go simple as it is.
- mlvljr 10y agoEvery language should (and then, you get OCaml, as I get t :)). Depends on whether you want you coders to apply enough brainpower while at work, sadly.
- deleted 10y ago[deleted]
- ungzd 10y agoProposal: Algol should have dependent types.
- amhunt 10y agoSitting in a lecture by Kernighan rn and he says GO will NOT be implementing generics
- AzzieElbab 10y agoIf you google "brutally practical" you will get "uninspired hack". Either that or the whole thing is simply pre-alpha
- bsaul 10y agoCould anyone here tell me why, in practice, it isn't possible to write generic algorithms such as sorting or Red/Black T using interfaces only in GO ? It seems like having interfaces such as "comparable, equatable,etc" should work in theory. I've read somewhere that it was memory usage related, but i've got trouble picturing why (maybe an example would help)
- NateDad 10y agoI work on juju (https://github.com/juju/juju https://github.com/juju/juju), which all told is about 1M LOC. In my almost 3 years on the project, I have not been bothered by lack of generics, basically at all (and I worked for 10 years in C# on projects that used a lot of generics, so it's not like I don't know what I'm missing). Do we have 67 implementations of sort.Interface? Sure. Is that, by any stretch of the imagination, a significantly difficult part of my job? No. Juju is a distributed application that supports running across thousands of machines on all the major clouds, on OSes including CentOS, Ubuntu, Windows, and OSX, on architectures including amd64, x86, PPC64EL, s390x... and stores data in a replicated mongoDB and uses RPC over websockets to talk between machines. The difficult problems are all either intrinsic to the solution space (e.g. supporting different storage back ends for each cloud), or problems we brought on ourselves (what do you mean the unit tests have to spin up a full mongodb instance?). Generics would not make our codebase significantly better, more maintainable, or easier to understand.
- jdcarter 10y agoI've had a very similar experience from about 3 years of writing Go. The lack of generics hardly affected me. When it did, it was dead simple to write the type-specific code and move on. I've been working on a Java project recently, and by contrast, this code base abuses generics to an almost pathological level. I've also been burned by Java's runtime type erasure, and wow that leads to some nasty bugs. (That's not the fault of generics in principle, but Java's poor implementation of them.) While I appreciate generics in theory, in practice I think Go is better as-is. Too often I've seen generics lead to complexity and abuse which greatly outweigh their utility.
- stcredzero 10y agoToo often I've seen [X] lead to complexity and abuse which greatly outweigh their utility. Programmer hubris is a problem. There was a widely acknowledged problem in Smalltalk with the overuse of #doesNotUnderstand: and other esoterica to do "clever" stuff which then makes it difficult for new programmers to debug and understand the system. There is a reason why certain methodologies emphasize "the simplest thing that could possibly work." As a group, we programmers sometimes waste our own and other's time being too clever by half...an order of magnitude. (Is it any wonder why our estimates are often off by that much?)
- kafeltz 10y agoRich Hickey could play on golang, this guy is so fascinated by simplicity too.
- rebnoob 10y ago"Let the machine do the work." [1] By Rob Pike, a man of contradictions. [1] https://blog.golang.org/generate https://blog.golang.org/generate
- plq 10y agoThere was a time when the only language with decent platform support had to have turing-complete meta-programming support, inheritance, polymorphism, lambdas, preprocessor, custom allocators, placement new, std::erase_if, etc, etc. because we were basically stuck with it. Those times are now way behind us. Today, there is a plethora of languages to choose from, each with their strengths and weaknesses, each most powerful in the niche it's designed for. Go is not a language with generics. If you need generics, don't use Go. Go should not have generics unless it's trying to dominate the world. And we all know that no language can achieve world domination nowadays, not anymore. So it should rather trying to be the best language possible in the niche it was designed for. That niche doesn't need generics. On the contrary, a vocal part of the community says generics would taint Go. Go doesn't have generics. It's however got a proper FFI. Use it. Or don't.
- tssuser 10y agoLet me give a concrete example of how I've been personally impacted by the lack of generics. My project makes liberal use of pointers to represent "optional" fields, since they need to be distinguished from the zero-type. Alternatives would be to have a boolean associated with every field, but that clutters the API and still faces a lot of the problems with using pointrs, such as: - Easy to forget to check that pointer != nil - Overloaded semantics: it's unclear whether a pointer represents an optional type, or is being used to pass-by-refrence (i.e. unclear whether a value should be treated read-only) - Need to deep copy every struct, which is easy to forget and inefficient (at least the reflect version) There are solutions to each of these points, but they all add complexity (e.g. generating code), and most take a lot of extra effort. With generics I could have Optional<T>, With a Get() function returning 2 values: the value type, and present (i.e. the way maps work). The caller is forced to handle both returns, making it much harder to forget to check it. A lot of arguments for generics focus on higher-level functional programming abstractions, but this is a simple and extremely common use-case, and the lack of a solution is responsible for many real-world bugs.
- sacado2 10y agotype Optional struct { stuff interface{} present bool } func (o Optional) Get() (interface{}, bool) { return o.stuff, o.present } func NewOptional(stuff interface{}) { return Optional(stuff, true) }
- kzhahou 10y agoCame for a Proposal. This article only provides motivation for generics. Are there any concrete proposals on the table? I don't recall seeing any, and it would be great to work from that and pick it apart. Otherwise, we're just arguing the opinion that they're useful, against the opinion that they'd soil the language.