There is a story about generics in Go. The story is, 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.
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!
>The story is, 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.
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.
I work with some old Java code that's a mix of generic-ised and not. Every time I see a method that returns a Collection I want to shout "COLLECTION OF WHAT?!?!".
Comprehending other people's non-generic code is a giant pain in the ass compared to reading code with generics.
A method might return, say, some URIs. These might be represented as URI objects or strings, depending on your preference (in some tighter areas of the code we might use String objects, because URIs can be expensive-ish to create, and we might know for sure that the strings in question are valid). If I have a method called getURIs, does it return URIs or Strings? Should the method be called getURIsAsStrings? Perhaps, but it makes for some pretty awkward (and long) method names.
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.
Naming conventions are often used as (IMHO) poor substitutions for type systems. A name is for the programmer. A type is for the computer AND the programmer.
Type safety, and the lack of fields in interfaces. In C you have to pass the size of the elements to quicksort, but in Go you can't do that without using the unsafe module. So you need a virtual Swap() method. And because Go needs to take a single interface, and interfaces in Go can't have fields, you need a Len() method as well.
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.
The simplicity of Go's syntax makes it really easy to use as a target for compile-time generated code, and all of the built-in parsing libraries in the standard lib make it really easy to interface such generated code with human-generated code and at the end of all of this you end up with something much more type-safe than you do with C macros.
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.
None that is publicly available that I'm aware of, unfortunately.
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.
Custom -- most of the code generation I've done has been about binding Go functionality into UI markup languages (similar to the way ActionScript binding in Flex works, for those who have used that) as opposed to generics-like functionality.
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.
The story is that the Go designers saw the value in generics and added a bunch of generic container types to the language. They are also saying that if your needs aren't covered by these built-ins, then you have to build something on your own and you cannot construct something that provides the safety and ease of the built-ins.
> 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.
The story is that generics for Go is an ongoing research project for the team. We are not going to put them into the language until we are sure that we have a satisfactory way of doing it and that the end result is a net win.
>The story is that generics for Go is an ongoing research project for the team.
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?
The various proposals have been circulated amongst a small group of core Go contributors. That has been sufficient to drive the process so far, with many options being explored in detail. The work continues to evolve.
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.
>We're not university professors. We're not publishing papers or other "researchy output".
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.
Well, I'm sorry, but I haven't seen this from following Go from a (small) distance -- and doing some work projects with it.
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.
Aren't you just kinda being a dick here? A go developer has directly responded to you multiple times, saying that this is a topic that they're actively researching. And you just keep replying with skepticism asking for actual proof.
No one owes you anything here. I hope you don't behave this way with other open source projects.
>And you just keep replying with skepticism asking for actual proof.
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.
You've misread my comments and are trying to make them into something they're not. I wasn't calling you out for criticizing Go or trying to discuss its shortcomings. I was calling you out for being a dick to Enneff. I think my original comment was fairly clear about this.
Anyways this is a pointless argument. I'm sure youre a great guy in person.
>You've misread my comments and are trying to make them into something they're not. I wasn't calling you out for criticizing Go or trying to discuss its shortcomings. I was calling you out for being a dick to Enneff.
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?
In general, I agree. Go doesn't have to be all things to all people, but it could be more than it is with a story about how it would add generics. I think a lot of people are disappointed that Go doesn't seem interested in going beyond the "systems language" level; we were excited to use Go in a range of applications but were disappointed by our inability to write generic map/reduce/fold/etc functions.
>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.
Let's remember that to the stakeholders, this stuff is just a means to an end. I'd like to see Go have generics as well, but after spending the last two weeks writing a service bus in Go, the work was by factors more productive than the same work I've done in C#, which seems to be trying to have every possible language feature ever created in it.
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).
Hmm, I haven't implemented anything complex in Go, but I have read a fair amount of code and looked at the "spec."
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.
For me it's the comparative noise level. C# is noisy enough. When combined with stick your code here framework and code generation, monkeying with IIS, and the rest of the msft box I'm thrown into regardless of app load and requirements, I just start detaching or worse am just worn out at the end of the day. Go asks for so little in the productivity I get in return. Haven't enjoyed writing code this much since my Modula-2 days.
> by factors more productive than the same work I've done in C#
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)
I measure my productivity in a language by how little code I can write to accomplish my goal. You seem to be saying the opposite?
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 =)
Shouldn't productivity be measured in how much time it takes to solve problems? The amount of code produced at the end is only relevant if typing is a significant portion of your time spent. Typing is rarely my bottleneck.
Agree that typing speed is not the bottleneck when writing code, but there is something to be said for writing fewer lines of code that are also easy to understand (ie. overly clever code that is concise is often a negative). That should make maintenance and debugging easier as there is less code in which to introduce bugs and less code to load into your brain when returning to it later.
No I wouldn't be saying I produce reams of boilerplate like it's a good thing ;) I meant, and I'm sure you've experience this, that the language doesn't get in the way of realizing the program that's still in my head. Every interruption spent tracking down some language quirk is probably double the time or more to get back into the flow of it. It's really a shame Microsoft doesn't do more to make C# more portable.
The reason you write less code in Go is because there is less complexity. Similar to F# vs C#:
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.
I don't see the irony. It's a contrast of a class based and object oriented language vs a functional language. The functional language leads to a much simpler call graph than the OOP language.
Is go really trying to stick to a "system level" language? The performance benchmarks I've seen seem to suggest it's no more suitable for that than Java, Haskell, and a variety of other "2 to 3 times slower than c" languages. Except I think Go might be the only one pushing itself as a system level language.
I think it's occupying a nice spot on the spectrum between say C and Ruby. If you're implementing some CRUD app with a few hotspots, maybe you'll implement the whole thing in Rails, then break it out into an SOA with golang services powering the hotspots. Finally if you really need to you can hand-tune the hottest spots with some C code inside of your Go services.
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!
Calling it a system level language is a disservice. It's great for servers and commandline utilities. Canonical is working on integrating go with QML to be able to write nice GUI code that runs on all major platforms.
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.
Totally agree. Go is a superb systems language. But I wouldn't use it for a CRUD web app, nor for quasi-exploratory data pipelines, which is where IMO such generic functional combinators are clutch. It is however awesome when you've nailed down the data pipeline and you want to get a big speed improvement in a fraction of the time required to build out in C/C++.
What makes Go a good "systems language"? Is it because it's fast? What about Java, Scala, Clojure, Haskell, C#, F#, Scheme, Ocaml, etc, which all have performance (speed of execution) similar to Go, are they good "systems languages" as well?
If it's not speed of execution then what makes Go a good systems language? The ability to fiddle bits? A small runtime?
I would use it for a CRUD app and I wish it had features that would support that. As an open-language, this input should be considered (alongside the input of the maintainers and other users of the language). I believe the top-comment here was saying that this conversation shouldn't be side-lined.
>There is a story about generics in Go. The story is, 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.
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.
Go seems to be picking up a lot of python/rubyists who are looking for a faster language that's not excessively verbose. I suspect that fraction of the community doesn't miss generics as a result of simply never having had them.
Dynamically-typed languages don't need generics just like they don't need interfaces. If everything is a duck and everything holds ducks, then you don't need generics.
The need for generics (or macro/template-based equivalents) naturally falls out of using a statically-typed language.
Disagree. Generics aren't just used to enable generic operations - they also provide clarity/documentation on what types are being passed around. As someone who spends a lot of time working on other people's (sometimes old and crufty) code, I find that invaluable.
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.
This is the reason that Go drove me to Haskell. These days I have fast type-checked programs with a more than 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.
I think the amount of time I spend working on Other People's Stuff probably influenced my comment there. While I obviously use and appreciate generics for their enabling of generic operations, I tend to primarily love them for their documenting/strictness-enforcing aspects.
> 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.
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.
A variety of complex programs are being built and deployed in plain C without generics, which makes it an open question as to whether they're required at all.
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!