How does Erlang solve it?
Dinamic languages don't need generics
Can you explain?
Proposal: Go should have generics
201–210 of 439 posts
Re: Proposal: Go should have generics
#202I 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 ev…
I had the same feeling first. But practically in my code, I found that ok, you need to copy/paste a bit first but then if it works it stays there, you are not "sorting" new kind of "types" every day. The time spent on coding is way more "around" the algorithms than "within" them. I suppose that we will see more and more code generators which will practically remove the need of generics. We already use them without co…
If code generation is used to make up for something missing in a language (be it generics, metaprogramming etc.) then that's a pretty clear sign something is wrong.
It's definitely acceptable to use a workaround for a missing feature once or twice in a language, because no language is perfect, and no language benefits from being burdened with all features imaginable.
But if a workaround becomes part of the day-to-day workflow, then you are likely using the wrong language.
Examples could be: using (textual) code generation for generics, or using type annotations throughout a dynamic language project.
Re: Proposal: Go should have generics
#203can 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.
Re: Proposal: Go should have generics
#204Earlier quoted context omitted.
This is what people mean when they say that Go has disregarded everything we learned in the programming language community in the last decades. Sure, some people are productive in it and that's fine - but for those of us who have worked in better languages taking the step down is unattractive.
I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.
He who takes his examples of generics from C++ and Java has a huge blind spot. The FP crowd came up with simple and useable generics (Hindley-Milner type inference) in 1982.
It's like Go's creators haven't even read Pierce's Types and Programming languages. This is inexcusable. Even more so from Rob Pike and Ken Thomson —you'd expect better from such big shots.
Re: Proposal: Go should have generics
#205Can 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++.
Re: Proposal: Go should have generics
#206Earlier quoted context omitted.
No, it's the opposite. It would appeal to people who built large Go codebases and eventually realised that they were tied to a toolchain that was years behind the state of the art. A Go for the JVM would immediately give Go developers much better optimising compilers, high quality cross platform IDE-integrated debugging and profiling, much stronger garbage collectors, ability to access the large quantity of Java libr…
JVM cannot appeal to Go developers, because compiler is a significant factor why people choose Go in the first place.
There are quite a few native compilers for Java, the difference is that the best ones aren't free.
Re: Proposal: Go should have generics
#207Earlier quoted context omitted.
Generics are a very simple feature as implemented in, for example, SML or OCaml. They're much simpler than Go interfaces, in fact.
Generics become complicated when you have other subtype relationships, don't they? (That's why SML, OCaml and Haskell don't really do inheritance, isn't it?)
If I have generics, first class functions, and garbage collection, frankly I don't care about sub-typing.
Re: Proposal: Go should have generics
#208Earlier quoted context omitted.
This is what people mean when they say that Go has disregarded everything we learned in the programming language community in the last decades. Sure, some people are productive in it and that's fine - but for those of us who have worked in better languages taking the step down is unattractive.
I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.
Go is thriving because it is Google sponsored.
If it came from "Joe the dev" no one at HN would give it a second look.
Re: Proposal: Go should have generics
#209After 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.
Rob Pike's repository 'filter'[0] contains implementations of map ("Apply"), filter ("Choose", I believe), and fold/reduce ("Reduce"). The code is an ugly mess, and the implementation shows that he probably hasn't used any of these standard functions in other languages (see the weird permutations of 'filter' in apply.go, or my patch for his fold/reduce implementation[1]). The README is also quite arrogant, IMO. > I w…
I quite like the logical progression though:
+ People keep telling me we should be able to implement a map function in go.
+ I implemented a map function in go.
+ The map function was ugly, slow, unsafe and generally an abomination.
Conclusion? You don't need a map function in go.
You may not agree but you have to admire his dedication to the One True Way whatever is put in his way. Even if it's him that's erecting pretty impressive roadblock himself.
Re: Proposal: Go should have generics
#210Earlier quoted context omitted.
>You can get 10msec pauses or less with heaps >100GB with HotSpot if you tune things well and use the latest GC (G1). For what percentile of collections? I'm not wasting my time with incessant GC tuning only to delay that 5 minute stop the world pause for a bit longer. It's still going to hit eventually. For projects that might grow into that sort of heap size I use C++ (with an eye on Rust for the future). You are r…
In a properly tuned system with sufficient CPU capacity there should never be any full GC pauses with G1. To get 10msec pause times with such huge heaps requires burning a LOT of CPU time with the standard JDK collectors because they can trade off pause latency vs CPU time. This presentation shows tuning with 100msec as the target: http://www.slideshare.net/HBaseCon/dev-session-7-49202969 Key points from the slides:…
>In a properly tuned system with sufficient CPU capacity there should never be any full GC pauses with G1.
So you use a language without value types that makes you pay for two or three times more memory than comparable languages, and then you spend your time re-tuning the GC every time your allocation or usage patterns change. Then you hope to never trigger a full GC that could stall the VM for many seconds (or in extreme cases that I have seen even minutes). That makes very little sense to me.
I cannot speak to the performance of the current Go GC for 100G heap sizes. I never tried it and I haven't read anything about it. It's not my language of choice for that sort of task either.