I feel like not including generics is a huge oversight. Also, the way many go aficionados discuss this over at golang-nuts put me off a great deal.

to some extent, i think that the demand for generics is based on familiarity.

for example, long ago, i was looking at the source for some of the go libraries and couldn't understand why they had cut+paste code. when i asked on stackoverflow the unaminous answer was "because go doesn't support generics". you can see the discussion here - http://stackoverflow.com/questions/6645329/why-does-the-go-i...

BUT if you read that thread, and the discussion under the first answer, you'll see that there is an apparently reasonable solution without generics. that seemed like an obvious approach to me (coming, i guess, more from python and fp), but one that wasn't obvious to anyone answering (coming, i guess, more from java and c).

i have no evidence that this is a general problem, but it surprised me at the time. ever since i have been suspicious of people complaining about the lack of generics (disclaimer: i don't use go myself - when i looked at it i thought that it was clear improvement on c/c++/java, but could have been even better if they had been more open to ideas from fp - http://acooke.org/cute/GoRocksHow0.html ; in other words, i'd be happy to use it at work instead of c (current project), but if i can choose myself i'm more likely to go with a more functional approach).

I think your so question shows exactly why generics are useful. A solution where you pass a callback predicate to the iterating function would work in Go, but be much slower than one in which the predicate logic can be inlined. E.g. if your image is 1920x1200 you would need to call the function that checks if the pixel is opaque 2.3 million times. That approach works ok in Python and Ruby which do not mind being a little on the slow side, but Go is supposed to be closer to the metal so something more efficient is needed.

i don't disagree with what you're saying (and i raise the question of efficiency in the link). my point was more about the sociology of the complaints: i think most people are complaining because they're used to generics and don't have the tools/smarts to solve problems in alternative ways.

i think the general conclusion from this thread is that generics would be useful because, at the moment, if you want top performance, you need to have type unsafe code in critical loops.

that sounds quite reasonable to me...

...so maybe i am just an arrogant bastard that doesn't think much of fellow programmers. but i suspect that most people, when they complain about generics are not making that argument. they're simply complaining because it's not what they are used to.

as i say, i may be wrong. i may be a horrible man. if people want to convert/improve me i suggest they start making comments that are a bit more nuanced than "i miss generics".

You can write a C++ style pre processer to compute efficient specialized methods from a template definition. The only problem is winning community adoption over the objections of the go dev team.

> to some extent, i think that the demand for generics is based on familiarity.

Such as the familiarity of java developers who had to wait for a decade to get generics? The familiarity of C developers where void*? Or the familiarity of Python developers where "whatever"?

This claim doesn't check out.

What is an example of a use case for generics that can't be done, or is significantly less convenient to do, with interfaces? It sounds like there is at least some thought that generics may be included at some point, but I really haven't missed them thus far.

I have to agree that the lack of generics is one of the biggest holes in Go.

Common container data structures are one example. You can't write, say, a generic binary search tree in Go, unless you wrap all your data in an interface. While possible, this means you have to downcast all over the place.

The built-in map, while useful, is limited in how far it goes.

Maybe I'm just spoiled by the STL and the Java collections libraries.

A lot of functional constructs heavily rely on parametric polymorphism. For example:

    map :: (a -> b) -> [a] -> [b]

Interfaces can't provide this type of code reuse.

Slight nitpick, you can do this, just not with type safety. Type safety is the real reason generics are better than interfaces.

If you're attached to FP style you shouldn't choose an imperative language in the first place.

It has been pretty conclusively demonstrated at this point that a basic suite of "weak" FP tools is pretty useful in any language. No serious modern language should try to work without convenient closures and a functioning map and filter statement/function/whatever. This hasn't got anything to do with purity or academic goodness, and everything to do with the fact that languages like Python or Ruby, which are emphatically not FP languages, have simply shown such things to be indispensable tools for concise code.

Pretty useful: yes.

Essential: no.

Map/Filter introduce several new semantic concepts to a language. I think they were avoided for simplicity's sake and the fact you can achieve the same result with a for loop, even if it is slightly less concise.

> Map/Filter introduce several new semantic concepts to a language.

No they don't. If you already have first-class functions (Go does) and some sort of sequence type (Go does), you have map/filter. There's no new semantic concepts.

With this standard for "essential" you may as well just drop down into assembly language.

The only added simplicity here is for the compiler writers, not the end users.

numbers = map(numbers, func(n int) int { return n * n })

for i, n := range numbers { numbers[i] = n * n }

Sorry, but I do not see a difference in the order of assembly language vs. high-level language.

The difference is small because map is trivial, but the implications of using higher order functions isn't. Even something like trees sees a divergence between the styles (not necessarily in the order of assembly language vs. high-level, but certainly more than you're making out).

Higher order functions are really useful for splitting apart navigation of a data structure and the processing of the data contained within it.

Given that you can use purely higher order functions for control flow, I wouldn't say one is more essential than the other.

Now try it on a more complex type. Then try and compose various operations. Then swap out the container type.

(Unfortunately, formatting is lost)

a) With a more complex type (I don't see how this would affect one more than the other)

Functional would be:

foos = map(foos, func(f Foo) Foo { return Foo{f.A * f.A, f.B * f.B} })

Iterative is:

for i, f := range foos { foos[i] = Foo{f.A * f.A, f.B * f.B} }

b) Composing various operations. Composing filter + map:

Functional would be:

x := filter(map(numbers, func(n int) int { return n * n }), func(n int) bool { return n % 2 == 0 })

Iterative is:

x := make([]int, 0); for _, n := range numbers { sq := n * n; if sq % 2 == 0 { x = append(x, sq) } }

c) Swapping the container type is just a matter of swapping "_, n := range numbers".

> With a more complex type (I don't see how this would affect one more than the other)

It does because the discussion is about generics. The fact that you're writing out types for one and not the other makes your comparisons a bit disingenuous, though I understand if Go isn't very good at functional programming.

b) Composing various operations. Composing filter + map:

As you keep building them up the imperative style will have more code overhead and less efficiency.

> c) Swapping the container type is just a matter of swapping "_, n := range numbers".

This isn't true since the functional one could easily swap out to use an infinite data source whereas the imperative will be constrained to the arrays you're already using.

a) Generics would not make the function signatures shorter. You would have to introduce yet another concept: type inference for the signatures of anonymous functions.

b) No, it will not be less efficient. It's all done within one loop, in-place. You can compose everything inside the body of the loop. A functional language would do the same if it's intelligent.

c) You can easily create an infinite data source in Go with the generator pattern:

numbers := make(chan int); go func() { for i := 0; ; i++ { numbers <- i } }()

for n := range numbers {...}

> Generics would not make the function signatures shorter. You would have to introduce yet another concept: type inference for the signatures of anonymous functions

Yes, I should have said type inference obviously. I can't think of a decent functional language that doesn't have type inference though.

> No, it will not be less efficient. It's all done within one loop, in-place. You can compose everything inside the body of the loop. A functional language would do the same if it's intelligent.

If it's all done in one loop then it isn't composing. It's writing custom code every time you need to do something.

> You can easily create an infinite data source in Go with the generator pattern:

That's nice, you only need to change all of your code to do so. The functional version doesn't have that problem.

================

Please note that if your comment thread starts getting squished against the right side of the page like this, it might be time to move the conversation off of HN.

================

An infinite data source? That sounds like a thunk (which is easy to implement), or perhaps it really is a channel?

The beauty is - it doesn't _matter_.

It could be a linked list that links back to it's own head. It could be a network stream, or a series of events from an input device. The program doesn't have to care.

You should read up on channels and generators then. The source doesn't matter, just the type contract.

It's a different way of approaching things. I'd say that golang was stream-based rather than functional or imperative.

We're WAY past the point where it is acceptable to pretend basics like map and filter are some esoteric functional thing. Every reasonable language has them, and no language without them is worth even considering.

map and filter are no problem:

https://github.com/tcard/functional

I can't say I've actually needed to use map or filter. You can, much as people did for the last 30 years and still do with C, quite happily do this sort of stuff with a for loop...

People spent years without loops too, "quite happily" doing it with jumps. Lacking useful abstractions is not a case of preference, it is being inferior.

It's not that there's a lot of things that you flat-out can't do, it's that you can't do those things in a type-safe manner. The type system isn't capable of representing what you're trying to do. This seems like an odd omission in a language that otherwise has static typing.

I suspect this is why a lot of people who've jumped on the Golang bandwagon come from Python & Ruby: they're already used to no compile-time type safety, so they're not missing anything. For people who like type systems and have a style of programming that relies upon them, Go doesn't give them the tools they need to be productive.

In Steve Yegge's terms: C++ is a pretty software-conservative update to C (it even has backwards-compatible syntax). Meanwhile, Go is a pretty software-liberal update (slightly to the right of Python). G simply does not support a software-conservative programming style. Consequently, Go's adoption has mostly come from software-liberal communities.

I hate those terms, but by his definitions, Go is statically typed and defaults to not including features if they think they might be misused. Doesn't sound that liberal to me, compared to, say, Ruby with monkey-patching.

I tend to use generics alongside reflection a lot, for example I might use a Mapper<TFrom, TTo> when mapping between different representations (an object and associated service contract being one example).

The mapper can take care of almost everything using a few conventions and reflection, and for anything where those conventions don't cover it you plug in a little custom code (inherit from Mapper<,> or use composition).

Not sure how you’d handle that sort of case in Go without generics?

Repository style generic data access layers: http://stackoverflow.com/questions/11914712/writing-generic-...

There are several generic data access layers implemented in Go: standard JSON package, Gustavo's BSON package, App Engine Data store and more. They all use the reflect package internally.

Yeah, it basically makes the answer to the original question an emphatic "No".

Have you checked out Rust (http://rust-lang.org)? They seem to be closer to what Go's original goals were, with generics, proper RAII, etc.

It's not an oversight, it is a tradeoff. Check Russ Cox'sswtch.com website for details. You can write generic functions with reflection.

The creators of Go have cluster a.k.a. cloud computing in mind: http://www.youtube.com/watch?v=FTl0tl9BGdc And the predictions in this article are about PaaS / IaaS / orchestration, which have not a lot to do with GUI.

Implementing a top-class GUI toolkit that is not just a binding to an existing one would be at least half a decade of work. And when it's done all GUIs will be rendered by web views anyway. The web is the presentation layer of the future. Classic desktop widget sets like QtGui or Swing will fit nowhere, because all the consumer operating systems like iOS, OS X, Android and Windows 8+ will have highly custom user interface paradigms, which won't be mappable to each other by some cross-platform thing.

>just a web view anyways

This. Go makes it fantastically simple to go from 0-to-web-server.

There were a few projects I wanted to write in Go, but avoided because of needing a GUI.

Then I remembered: I can just bolt a web-page onto my app, and I get a GUI for free [assuming knowledge of HTML/CSS/JS].

Even better: that GUI will work on any computer with a modern web-browser, including my phones. If you stick to standards, it should even be a reasonably consistent UX across the newer browsers.

---

While I would still _like_ to see a good UI toolkit for Go, I really think it's less of a necessity than most would have you believe.

Agreed.

I'm playing with the idea of a Cairo/Postscript type library with X, Win32, Quartz backends in Golang which would be a good foundation for such a thing.

I have got precisely nowhere apart from trying to connect to an X server unsuccessfully though :)

Idea: a Go HTML GUI toolkit designed to allow writing a GUI in real Go code without thinking about html, css, ajax, etc. It just abstracts that stuff away, providing a much more standardized/typical GUI programming experience, all the while running a web server and generating HTML on the fly.

I really wish all languages had an IDE that included an interface builder as nice as Visual Studio. Making a VB.NET program really is rapid application development, because in most cases you don't even need to write more than a dozen or so lines of code.

I find programming to be easy (relatively). I find interfaces to be almost insurmountably difficult. That's the only reason I stick exclusively to command-line programs.

>I find interfaces to be almost insurmountably difficult.

Odd. Here's my 5 min explanation of how GUI programming works:

You have a bunch of objects that are responsible for generating events and painting themselves to the screen. They exist in hierarchies. You have objects that coordinate the transitions between different display states by swapping out different hierarchies (view FSMs, really.) You communicate with your domain backend thread/process through some kind of command channel. When your domain models change, they publish some events that go back through that channel to notify your display hierarchies so they can update themselves. Everything is async and through message passing.

The difficulties can be in a) setting up your hierarchy of display objects and b) getting your event routing / updating to happen in a clean way. Oh yea, and c) handling partially-complete domain models in the ui ;)

Cocoa/CocoaTouch and Flex are both quite nice environments for gui programming. I haven't used MFC, winforms or xaml/winrt..

Full disclaimer: I haven't done much UI (outside of HTML/CSS/JS, that is)... I dabbled with Visual Basic and the associated tooling (WinForms, at the time) during my college courses.

Of everything you describe, I think the area I struggled most with was:

>getting your event routing / updating to happen in a __clean__ way.

I was a naive and young programmer, so I'll withhold any criticisms towards WinForms, but the event routing was a _mess_ by the end of that project.

> I find programming to be easy (relatively). I find interfaces to be almost insurmountably difficult.

That's a personality type (mine too). Probably best to bite the bullet with HTML/CSS. I think non-web interface builders are a thing of the past. Which is too bad, because CSS is a monster to master.

I think developers will stay on traditional desktop systems, most likely a Linux since Apple and Microsoft target consumers(consuming videos, browsing the web or using only specific applications like Excel).

Developers need tools too so we shouldn't just abandon non-web technologies.

There's no reason why development tools couldn't be moved to the web. It's already happening with Github. And Github could include an IDE like Cloud9 one day.

I've been out of the OSX-space for a while. Are there a lot of apps using web views for their GUI? The only ones I can think of are Colloquy and Adium. Even then, they don't do the whole GUI as a web view, just the parts of the display that are theme-able.

> Are there a lot of apps using web views for their GUI?

No. [Edit: I'm talking about apps that use webviews make a native-looking app. Web apps don't qualify.]

All the apps developed for the web outnumber the apps in the app store.

Maybe I should have specified WebView rather than web view. IIRC, a WebView is a ready-to-go embed-able WebKit widget in the toolkit of OSX GUI developers.

Colloquy represents the chatroom text as a stream of XML, which it uses XSLT themes to translate into HTML, which is displayed in a WebView. I'm sure Adium does something similar.

"Using HTML/CSS/JS as the new GUI medium" doesn't limit itself to just running stuff in a traditional browser. I was under the assumption that we were talking about making HTML/CSS/JS the new GUI layer, even for native apps.

There are a few GUI toolkits in the works, it seems.

http://go-lang.cat-v.org/library-bindings

Check out the "GUIs and Widget Toolkits" section.

top class GUI toolkit? come back in a few years

I'm waiting for a mature GUI library to start something serious in Go.

I'd be very^2 interested to see how the concurrency primitives of Go help graphical applications.

Given that Rob created one of Go's ancestors using the same CSP concurrency model back in the 80's precisely to build GUI apps, I think it should work quite well:

http://doc.cat-v.org/bell_labs/squeak/

Ha! didn't know he worked specifically in this context, thanks a lot. I'm even more impatient now.