Golang doesn't have to be all things to all people, nor does it have to fulfill every programming task any one developer has.
I would be just as happy at this point to see the Golang team put generics to rest. And I like generics, and have been annoyed by their absence in Golang before!
This. The same can be said for C as well, but C is not memory safe and Go is- so it wasn't immediately obvious the same would hold for Go.
I used to use generics/templates in Java/C#/C++ a lot, and at first I missed them in Go, but now, after writing Go full time for 2+ years- I no longer miss them more than once or twice every few months... I think generics are great, but also greatly overused.
It's boilerplate, which generic methods would avoid.
There are shortcuts for sorting common types by their natural order in Go, so you only have to write this for custom types or custom orderings.
Could you explain why Go needs an interface with 3 methods?
Go has no such "blessed" precompiler-macro system.
Templates/macros are an ugly solution, but they are a solution.
So yeah, the toolset may not have anything like the C's preprocessor (the lack of which is a blessing, not a curse, IMO), but that's fine, if you're sure you really need such a thing just spend half a day writing your own in Go that is specific to your project's needs and make that a part of your local build process.
No real tooling either other than whatever you choose to use for the build process. For the projects I've done this for that ends up being a very simple Makefile which does a 'go run' on the code generation engine code prior to a 'go build' of the resulting combined package of generated & hand-written code.
[1] http://clipperhouse.github.io/gen/ ("A library for bringing generics-like functionality to Go")
I've never used gen, it looks pretty nice though, at least based on the linked docs and it is probably a good answer to Pxtl's question about publicly available examples.
Tangential, but a decent example of that sort of thing, a generic red-black tree written entirely in the C preprocessor: http://www.canonware.com/download/rb/rb_newer/rb.h
This should be a book or a blog. Seems like the most powerful features of languages are often the downfall of a project. Proxies based on #doesNotUnderstand: or method_missing can be awesome and they can also be misused to render a project incomprehensible. The same goes for macros in C, macros in Lisp, and generics.
Generics makes code far more readable, maintainable and testable.
Comprehending other people's non-generic code is a giant pain in the ass compared to reading code with generics.
The method was named something like "getCollectionOfSomething()"? If so, you might want to put some of the blame on the method naming choices.
Even if you do have a sensible naming scheme that makes the return type clear, it's rather beside the point. If I have a choice between relying on coding convention or generics, I know what option I'm going to pick.
But imho the method should not be named for the compiler-type of it's return value (unless it's a type converter like int2string or similar).
It should be named for the bizlogic/semantic type:
So..not "getURIs()", but better "getBackendPoolMembers()" or "getBackendPoolMemberURIs()" if you have more than one way of representing them.
Long method names are fine. Everyone uses autocomplete. Choose good names and rename them often as the meaning of the code changes over time.
var stuff []MyType
> a variety of complex programs are being built and deployed in Golang without generics, which makes it an open question as to whether they're required at all.
And a variety of complex programs have been built and deployed in assembler. There are arguments against adding generics, but the fact that people get by without them isn't a convincing one.
Perhaps those people working on it can give an update or some info on their work? Even a "we tried this approach, it's too cumbersome so we abandoned it" or "we pursue this idea, but we're still ways off" etc, would suffice.
No one owes you anything here. I hope you don't behave this way with other open source projects.
Anyway, just consider what their behavior says about how they think of their users.
Should I just accept the same kind of answer we've had for 4 years on the Go webpage, and move on?
You talk about wanting "actual proof" as if it's a bad thing. Where's the harm in wanting "actual proof"? Did Ken Ham proved it overrated?
Notice how the top voted comment in this thread, showing a clear community interest, makes the same point:
"I'm surprised at the lack of progress in generics for Go. But more than progress, I'm surprised at the lack of a story about generics in Go. Yes, the FAQ waves its hands at complexity, but the lack of discussion and/or proposals puzzle me."
>No one owes you anything here.
That doesn't preclude discussion, having questions and, yes, even doubting overly generic answers. Noone owes anything to the Python community either, but they are far more open with such things.
Perhaps I want to know if Go wants to be a real community project, or a "developed by a core team at Google in secrecy you get what we want you to get when we want you to get it" thing.
Yes. Clearly its time to find another language that better suits your needs and is managed more to your liking.
Isn't that like a really inadequate answer to people trying to critisize/improve things? I sure get the rednecky "If you don't like this country mister, then go live somewhere else" vibe from it.
Clearly the fact that you are satisfied with Go doesn't stop you from inteferring with people having discussions about its (perceived) shortcomings.
So why should my disatisfaction with it prevent me from discussing it Especially if its a dissatisfaction with some aspects of it, and not the whole thing? By the same logic, nobody should use anything (nor complain about anything), since all languages have shortcomings that they don't like.
Anyways this is a pointless argument. I'm sure youre a great guy in person.
Well, we appreared as representing the Go team, and then rehashed the old "we're actively looking into it" response. I was not trying to be a dick, just wanted something more concrete than that.
Plus, I felt like he contradicted himself, when replying to another comment and said something to the effect that they didn't do anything about generics because they are busy building other things. So I had to ask, which was it, were they actively looking into it or didn't have time and had it as a low priority?
I don't see that in real life. That's just a "shut up" story employed like 4 years ago. If it's an "ongoing research" project, where's any researchy output?
"Python 3000" was once a research project and had tons of proposals and research done on various features. Closures in Java were researched, and there were implementations tested. ES6 was an ongoing effort to add features to Javascript, and there have been test implementations, shims, etc before it's out.
All languages that wanted to add a feature had attempts by various key developers to add these to them, proposals, papers, testing, requests for comments, etc. Where are those regarding Go and generics?
We're not university professors. We're not publishing papers or other "researchy output". We're just trying to get stuff done. If we publish all the works-in-progress we will distract the community from the more pressing concerns of today's Go programmers. We all already spend way too much time reading mail, and generics is a hot topic (obviously). The last thing we need is more (redundant) mail.
Well neither is Larry Wall, or Guido (well, is not working directly as such), or the Rust guys. But they still manage to put out proposals and describe their approaches to adding features, their progress and such.
I didn't mean "researchy output" in the academic sense. Just the results of looking into it, basically. Could be just a blog post. Or some email.
>I would be just as happy at this point to see the Golang team put generics to rest.
Clarity on this point would be great. And update the FAQ.
As it is, Rust is looking better and better as Mozilla tightens it up.
EDIT: I added the Rust note after tptacek added his reply. Apologies to him.
If it's not speed of execution then what makes Go a good systems language? The ability to fiddle bits? A small runtime?
One thing I've been enjoying out of the Go community is narrowly scoped command line tools. Heroku's CLI client runs on Ruby, but there's an `hk` variant written in Go that offers 90% of the functionality with a fraction of the runtime. More of that, please!
Go is actually quite well suited to GUI code, because it handles concurrent work very easily (i.e. work on the gui thread vs. work on a non-gui thread).
About the only thing you can't do nicely in go is write a domain specific language, the way you can in other languages that allow operator overloading.
Anything you might think about writing in Java or C# you can write easily in Go (once the GoQML stuff is ready that'll include GUI code). Most things you might want to write in python or ruby you can write easily in go (as long as you don't need monkey patching).
And note, I mean "Would be pleasant to write in Go" not "Would be possible but painful to write in Go"
If you're doing a lot of vector and matrices math, Go might not be the best language, since you can't operator overload and thus can't make the code look like the math it's trying to replicate. It would still work and would still be fast and accurate and nicely concurrent... but most people doing that kind of math programming have come to expect that parts of their code will look like math, and in Go it won't.
Sure generics would be nice, but getting my shit done and moving on to the next challenge is even nicer. Hopefully some carefully thought out additions to Go will allow me to have all this goodness at some point.
Sorry for drift, but I have to put in a word for formalized pre/post conditions in Go. Really enjoyed that stuff in Eiffel, and I think it would play in well with the judicious lack of exceptions (which I like).
are you exaggerating here? C# is already the most productive language in my toolkit. It's easy to write reams of code that just works in C#. I should have a look at Go then. (edit forgot a word)
EDIT: I guess you are saying something slightly different: that you can produce reams of C# code that works out of the box without many iterations. "reams" to me implies boilerplate & excessive ceremony, but I shouldn't assume that about your work =)
http://fpbridge.co.uk/why-fsharp.html (checkout the call graph comparisons. I believe a Haskell call graph would be similar, but I could be very wrong.
What language feature(s) would you say greatly assisted you in Go?
There's a credible argument that C# is a very complicated language (it is relatively old and has undergone a significant amount of iterations, thus is quite large), but I don't usually find that programmers are defining their own subset of the language to program in (a la C++), which usually means that the complexity isn't that large for me.
If you have any specific complaints I would love to know them as C# is being actively developed right this second, including new language features (well, not by me, I'm on vacation :)).
If you feel that HN is the best forum, please feel free to forward them to the email in my profile.
The same argument could be used against adding closures to Java. After all "complex programs are being built and deployed without them". And yet, everyone thinks that it's a good idea that should have happened years before.
I think the argument is a variation of "I can do stuff in assembly just fine, why I'd need a higher level language?".
>Golang doesn't have to be all things to all people, nor does it have to fulfill every programming task any one developer has.
Well, generics are pretty basic to talk about having them as "being all things to all people". It's not like the majority of users testing or using Go regularly ask for all kinds of exotic features. The vast majority, judging from the mailing list, blog posts, articles etc, just have this major gripe.
I thought the whole point of picking a language like Ruby was to use a language in which you can describe what you want, instead of how you want it.
Boy oh boy do I ever miss collection-level constructs like map and reduce in Go. I just don't think of them as 'generics' because I'm not very well-versed in statically typed languages.
I still bite the bullet and use Go anyway when it feels appropriate, because I can get fast type-checked programs with a reasonably quick prototyping cycle.
Plus after you get types down well enough, you can largely pretend you are using a dynamic language. For instance sometimes I write my functions, make sure they work right, check the type ghci says they are in the repl, and add the type annotation.
The need for generics (or macro/template-based equivalents) naturally falls out of using a statically-typed language.
Similarly, a variety of complex programs are being built and deployed in [any other language] without Go, which makes it an open question as to whether Go is required at all.
My point isn't that Go isn't needed. It's that this argument against generics in Go is hypocritical and contradictory to the whole reason Go exists.