8 ms·
Go generics proposal moves to “likely accept”
- sam0x17 6y agoMeanwhile Crystal lang has had generics for years and years. Just saying :D That said, super excited to see Go maturing to the point where they address the #1 complaint about the language. Maybe I'll actually pick it up once this goes through!
- unit_circle 6y agolol
- throwaway894345 6y agoI don't know why "having generics" is regarded as an end unto itself, or even a particularly important feature. The more experienced I've become as a developer, the more I realize that the things that matter tend to be tooling, ecosystem, learning curve, documentation, standards, performance, etc. The things that tend not to matter so much are type system particulars. If people can make crazy money with dynamically typed languages, having a type system that provides static guarantees for 95% of use cases (beyond which you have to opt into dynamic typing via interface{}) is honestly fine. It's not elegant, but it gets the job done for a huge swath of software. Generics are nice to have, but I think people blow them wildly out of proportion. EDIT: My implicit criterion for programming languages is the extent to which they facilitate software development, not some pursuit of elegance unto itself (although I fully empathize with the latter). These two things are not particularly congruent, but I often get the vibe that much criticism of Go assumes that it exists to be elegant instead of practical.
- tptacek 6y agoBetter just to flag language war comments, which otherwise strangle threads like kudzu.
- jacques_chester 6y ago> Generics are nice to have, but I think people blow them wildly out of proportion. The main alternative is code generation, which is slow, brittle and hostile to easy version control. I'd rather have a code type system than a system typing out code.
- erik_seaberg 6y agoCodegen can work around weakness in a language, but the key is a build system that generates code, compiles it, and then throws it away. Checking it in is a mistake, because you have to start reviewing it if there’s any possibility of editing it.
- throwaway894345 6y agoFully agree that generic type system is nicer than code generation; however, code generation thankfully isn't the only alternative nor even the best. Rather, as previously mentioned, we can use `interface{}` which is roughly the same as using dynamic types for the relevant bit of code. If people can make blockbuster apps with dynamically typed languages (100% of code paths are dynamically typed), it's really not a big deal that Go makes you drop into dynamic typing for <5% of code paths.
- jacques_chester 6y agoI don't see interface{} as an improvement over code generation.
- throwaway894345 6y agoI think you'll find that your opinion is very fringe, but by all means, go forth and use code generation.
- jacques_chester 6y agoMy opinion is that I greatly prefer generics to either.
- cy_hauser 6y agoCuts down on code and eases refactoring. Makes it faster to go from my mind to my code! (Once you get past the syntactical reading bump.) I'm really looking forward to really cleaning up some database and report code in particular. Bummed we won't see it in Go until at least 2022 though.
- throwaway894345 6y agoNo doubt, but again we're talking about a single digit percentage of code paths, and again there are entire blockbuster applications written without any static typing at all. It'll be a nice feature for sure, but it's not like world-class software wasn't written in Go before nor will Go+generics be a "Java-killer".
- eweise 6y agoWoot. looks like Go might jump decades from the 70s all the way up to mid 2000s language design.
- bitL 6y agoI still remember when lack of generics and other common stuff was one of their main selling points in the beginning.
- tptacek 6y agoIt remains a selling point, and a concern for some Go developers. There's a lot of cognitive overhead in pervasively-parameterized codebases, and many developers would rather spend their cycles thinking about their algorithms or their problem domain rather than following extra layers of indirection. I'm psyched to see generics arrive, but (I say this a lot) I write about as much Rust as I do Go these days, and there is definitely a cost to pervasive generics. I hope Go retains most of its original spirit, while at the same time making it easy for some people to write red-black trees or whatever.
- jacques_chester 6y agoIn practice I suspect this will lead to a Python 2/3-like fork in codebases, given the amount of electrons and emotions poured into the topic so far.
- tptacek 6y agoHow do you figure? Python 3 isn't compatible with Python 2.
- striking 6y agoI think that's the point of the reply, that we'll get codebases that aren't mutually compatible due to a resistance of or lean towards using generics. I'm not so certain that that's the case, but it is an interesting position nonetheless.
- Thaxll 6y agoThere is no such thing in Go since the language / runtime is very stable / backward compatible.
- grenoire 6y agoHas Go's interface{} single-handedly confused a generation of software developers, to the extent that they just couldn't understand the language? Is this what happens when languages reach an escape velocity of userbase?
- Thaxll 6y agointerface{} has a performance and security cost.
- nixpulvis 6y agoThat heuristic seems to be changing somewhat, depending on how and where you use those specific characters. It sounds like they plan to make `interface{}` the same as `any` in the type parameters. This makes sense if you forget anything you know about what an empty interface's implications were before, I think. Though I assume all the old reflection tricks are still valid, and potentially dangerous. I didn't read all the discussion, but I wonder if someone is thinking about detecting cases of existing `interface{}` and helping lift it to a generic constraint when possible. Or have I misunderstood something?
- ladberg 6y agoI also haven't read most the discussion, but I'm kinda hoping golint / go vet disallow using the reflection stuff on variables with type parameters. A lot of the design of generics is intended to remove runtime errors (and C++-esque) compile-time errors that require you to inspect the body of a function instead of the function type). Casting a generic would go against that.
- deleted 6y ago[deleted]
- majewsky 6y agoThese are two entirely different concepts: `any` is a compile-time construct, `interface{}` is a run-time construct. At any specific callsite, `any` resolves into one specific type that gets passed at that specific callsite. Buy `interface{}` can hold values of different types at the same callsite.
- Crash0v3rid3 6y agoI've been writing Go for years and never came across a problem that made me want to have generics. Anyone able to give me a simple example demonstrating why Go needs this?
- eweise 6y agoOne example would be to return a single value from a method containing Either the value you want, or the error. That way you could chain a bunch of method calls together and just check for errors at the end instead of checking after each method call.
- tptacek 6y agoPresumably anything you've used codegen to solve; for instance, it'll probably make SQL libraries a lot nicer to use.
- paedubucher 6y agoCode generation requires an additional build step. One thing I like about Go is that it feels like a scripting language (go run). I guess writing a numeric library, like Python's NumPy, is a lot more convenient using generics. But I've never tried...
- jacques_chester 6y agoIt depends on how you define "need". Golang could be replaced with a notation for NAND gates and still be able to "do" everything it does now. Yesterday I was in a pairing interview where I debugged and sped up some code. All-in-all I wound up with about 200 lines or so of Golang, including a lot of "yes, another loop" code. All I was doing, really, was mapping, forking and joining. Meanwhile in Java, I could have gotten most of this in about 20 lines withJava 8 Streams and .parallel(). Generics make that tractable.
- geodel 6y agoStrange. Why you keep torturing yourself with Go? Wouldn't just moving (or just staying?) on Java save you lot of grief. On the other hand a non-technical employer might force employees to new/fashionable things, so that could be the case.
- tptacek 6y agoSomeone here more familiar with the process could maybe summarize the next several steps and the timeline within which we might expect to get a "go" binary that can compile generics.
- pkaye 6y agoI think they have a proof of concept compiler (preprocessor?) already and it will be released in Aug of this year. https://go2goplay.golang.org/ https://go2goplay.golang.org/
- kyrra 6y agoproposal process is described here: https://github.com/golang/proposal https://github.com/golang/proposal And per https://blog.golang.org/generics-proposal https://blog.golang.org/generics-proposal, they hope to get this into the 1.18 release.
- at_a_remove 6y agoAt this point, I fear that, with time, languages will end up adopting each and every paradigm, all of the syntactic sugars, and so on. I escaped perl for a reason.
- paedubucher 6y agoLISP doesn't... but Racket and Clojure are already less puristic.
- biomcgary 6y agoMy main programming language before Go was Perl. I enjoy both languages but Go stays in my head better than Perl. However, I still use all my favorite perlvars for one-liners when munging data.
- paedubucher 6y agoIt's interesting how "angle brackets vs. square brackets" is such an issue for many Go programmers commenting on the generics proposals (including earlier ones). Maybe it is just revealing where those programmers are coming from. Java and C++? Angle brackets! Eiffel, Scala? Square brackets! Are there any parser considerations (like <Foo <Bar>> being an issue in C++, afair), or is it just taste (or Scala vs. C++ background)?
- fooker 6y ago> <Foo <Bar>> is an issue in C++ Used to be, a long time ago.
- enricozb 6y agoThere can be parser considerations: a < b can be greedily interpreted as a comparison, despite the next character being a > a [ b can be greedily interpreted as accessing a field in a map, despite the next character being a ] It may be easier to branch in one of those cases instead of the other. Not at all familiar with the potential issues (if any) in go, but this is from experience in writing a few languages.
- kyrra 6y agoThis is talked about here: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java https://go.googlesource.com/proposal/+/refs/heads/master/des... This line of code seems to say why is troublesome given Go's other syntax: a, b = w < x, y > (z)
- lhorie 6y ago> Are there any parser considerations Yes, in fact I can point to two different cases related to usage of angled brackets for generics: 1) Typescript claims to be a superset of JS, but it isn't, precisely because of this. `a<b,c>(d)` parses as a call to `a(d)` in TS, but parses to two comparisons in JS 2) D explicitly chose `!(foo)` syntax for templates over the `<foo>` syntax in order to avoid the parsing ambiguities problem
- asplake 6y ago
- lhorie 6y agoI don't follow go language design very closely, but I'm curious about how this is going to be implemented, if it actually becomes accepted. What comes immediately to mind is boxing in Java (i.e. you can't have a generic of a primitive). If go implements generics on top of boxing like Java did, isn't that basically just syntax sugar on top of `type T interface {}`? For example, today I can write "generic" go code like so: type T interface {} func main() { ints := []T {1,2,3,4} intsum := Sum(ints, func(a T, b T) T { return a.(int) + b.(int) }) fmt.Println(intsum.(int)) } func Sum(s []T, add func(T, T) T) T { var sum = s[0] for i := 1; i < len(s); i++ { sum = add(sum, s[i]) } return sum } The obvious issue is that the compiler defers type checking to runtime via the type assertions, so it's quite possible to panic on unexpected input; but then again the go compiler doesn't do anything against NPEs either. If the goal is to get the compiler to actually enforce generic types, wouldn't it run into exactly the same sort of problems Java 1.5(?) did in the 90s, or the compiler performance complaints that you get from languages like Rust?
- erik_seaberg 6y agoI believe Go will be monomorphizing Sum[T] and generating machine code for Sum[int](s []int, add func(int, int) int) rather than passing a []interface{} and type checking at runtime (the way Java would for a type-erased sum method). Ada did this, though you had to explicitly instantiate a generic for each type(s) you intended to use (some early C++ compilers also required this).
- lhorie 6y agoProbably a naive question, but couldn't it do the same optimization for the code above? I believe Javascript engines like V8 do something of that sort.
- erik_seaberg 6y agoA []int doesn’t have the same layout in memory as a []interface{}. You could copy the values to a new slice, but that’s expensive and it breaks anything relying on slices being mutable in place (this and covariance vs. contravariance is why Java won’t cast from int[] to Object[]).
- Jtsummers 6y agoFor those who are against generics (in general, or with Go specifically), what's your particular rationale? I find myself unable to create an effective anti-generics argument in the same way I can make a pro-generics argument. So far what I've seen here seem to be: - You can already use interface{} for something similar to generics - I don't want the language to become more complex - I can't conceive of how it'll be done efficiently/effectively - I don't, personally, see the value of generics (i.e., it wouldn't change any code I've ever written)
- gher-shyu3i 6y agoIt seems that most people who don't want generics are not able to provide good arguments in support of them. Just hand wavy ones like "I never needed them" or "complexity", even though complexity is inherent in reality. I've seen tons of golang code that would have been much simpler, and less error prone if the language had generics.
- loopz 6y agoSome people just don't want genetics. Maybe never seen the use. Some just want to avoid C++ templates and all those warts. I think the consensus is that Go community want it done right, or not at all.
- gher-shyu3i 6y agoDone right how? Practically every way that generics can be done is already done (C++, Java, C#, and Zig cover practically all bases). It seems very hand wavy for some people to say they want it done right, as if there's a magical way that hasn't been invented yet that will find its way into golang, which is known for being a language from the 70s as far as features go.
- loopz 6y agoIn a way promoting non-convoluted code. It's a property of the language which is like a side effect. Kind of reminds me of Ruby except Ruby was too dynamic to achieve it. C# is very readable too.