What Go Might Be Like With Generics

http://play.golang.org/p/SL7mMdtDiM

by sentiental • 13 years ago

39 48 13 years ago

play.golang.org

mseepgood2• 13 years ago

tl;dr: <T>

rogpeppe1• 13 years ago

How about this instead? http://play.golang.org/p/hED7faR0q_

bvaldivielso• 13 years ago

It is undeniable that generics are a quite demanded feature for golang.

We'll see how the language evolves, but I can't see them coming for a "long" time.

MetaCosm5• 13 years ago

I fully support language specialization -- that is kinda the point, it all ends up bits in the end. Rust is a completely different animal than Go yet I think both are awesome!

The idea that all languages have to cater to all people is silly. Generics are ALWAYS a trade-off. None is hard for developers, C++ style is terrible for compile (tons of code-gen, macro crap, duplication, de-duplication stages), and Java style (box-box-box-box) is slow at runtime.

The misunderstanding that generics are free and there lack of inclusion was an oversight rather than a choice is misguided. The Go team aren't fresh faced neophytes, they move with purpose.

Additionally -- if you want lots of features, there are LOTS of ways great languages for you! Leave the small, crazy cadre of people who don't mind C, think Lua is awesome and think Go is great to their (own) devices, we will be OK.

p_random• 13 years ago

you're awesome! you totally get the idea, people if the language does not fit your needs move on!!!! I mean seriously making all the fuss about generics even though that Go is being used in major projects (Cloudflare, UK.gov) yet we see more people arguing that is not right.

I'm glad Rob Pike and Co. don't give a rats a about such opinions.

fiorix• 13 years ago

<T>errible to my eyes.

f2f2• 13 years ago

is this trying to solve a particular problem or just pandering to the "... but generics!" crowd of trolls?

because it doesn't look like it's solving anything, it feels positively ugly, and there's no way we'll every shut those people up no matter how hard we try. there's no generics solution that will do that.

thankfully go's authors don't usually favour the internet's opinion on these matters, or we'd be dealing with something even uglier now.

girvo• 13 years ago

People who want generics, to solve real problems, in Go are trolls?

Gosh that word has lost all meaning at this point.

f2f2• 13 years ago

<T>. they know who they are.

Sir_Cmpwn6• 13 years ago

Is the only argument that Go users can come up with against generics is that they don't like the syntax? The pretentious nature of the Go community really puts me off from the language, especially when combined with some of the pretentious designs of Go itself.

marcus_holmes• 13 years ago

Is the only argument that Go users can come up with against generics is that they don't like the syntax?

Surely that's the best argument?

username223• 13 years ago

Surely that's the best argument?

As pathetic as it is, "syntax bad" is probably the best argument.

skybrian2• 13 years ago

No, the argument is that it's unclear how to fit it into the language.

Typically, generics are implemented using either code generation (causing code bloat) or type erasure (which requires boxing the type). They're not satisfied with either.

Sir_Cmpwn6• 13 years ago

A more accurate version of my comment would refer to "Go users" commenting in this thread.

smegel• 13 years ago

Doesn't Go already do runtime code generation to implement closures?

kristianp• 13 years ago

They probably wouldn't be happy with any impact on compile times either.

groovy2shoes2• 13 years ago

The "code generation = code bloat" argument really fails when you consider that the code generated for a generic function is code that would be written by hand in the absence of generics.

Compare:

    map f [1, 2, 3]
    map g [1.0, 2.0, 3.0]

Versus:

    integer_map f [1, 2, 3]
    double_map  g [1.0, 2.0, 3.0]

In both cases, you wind up with specialized versions of map (one for Integers and one for Doubles). The benefit of the generic version is that the programmer must only implement map once, and the compiler handles specializing it for various types. Without generics, the programmer has to write the specialized version for every type he needs the function for. This creates more tedium for the programmer, and does not reduce bloat in any way.

Caveat lector: Though my examples above are written in Haskell, I don't have enough knowledge of GHC internals to know whether it performs specialization this way. Nonetheless, it could be a reasonable approach for Go.

jksmith• 13 years ago

Interesting word to apply to anything related to golang. Seems more accurate to suggest that golang (and interest) is an alternative to pretentiousness.

vectorpush• 13 years ago

The pretentious nature of the Go community really puts me off from the language

I have had the exact opposite experience with the Go community. In particular, I've found community hubs like #go-nuts and the mailing list to be professional at worst and friendly at best, and always helpful.

some of the pretentious designs of Go itself.

How can a design be pretentious? Either you favor the design or you don't, but calling it pretentious is simply projecting your own emotions onto the language.

Sir_Cmpwn6• 13 years ago

They may not appear that way if you mesh well with the core ideas of Go. I once mentioned that Go does not fit into my usual project setup - I keep git repos in ~/sources. Go requires me to instead dedicate an entire directory structure to my entire Go workspace, which I have to keep seperate from the other sources. This could easily be avoided by letting me set enviornment variables that would relocate some of these folders (especially bin and pkg) to different places.

This is an example of how Go as a language is pretentious. It's way is the best way, even when no one else does it that way. The community becomes pretentious whenever you draw criticism against these core choices (note this mostly comes from #go-nuts, I haven't spent a lot of time on the mailing list). I like to believe that I can engage in well-reasoned discourse about these things, and I don't think I have seen the same degree of defensiveness and close-mindedness you might see from most other communities.

coldtea2• 13 years ago

I have had the exact opposite experience with the Go community. In particular, I've found community hubs like #go-nuts and the mailing list to be professional at worst and friendly at best, and always helpful.

That has not been my experience reading go-nuts. Almost any language improvement idea, however valid, is met with snark and you-re-doing-it-wrong answers. And there have been many, and from quite serious developers over the years.

rollo• 13 years ago

Eventually those who need static typing and parametric polymorphism will switch to Haskell anyway, where both are done in a much better way, both syntactically and implementation wise.

embwbam• 13 years ago

I use generics every day in typescript. I'm waiting to use go until it has them.

chimeracoder• 13 years ago

I have been writing Go daily at work for about a year and a half. It is now my primary language, and my default choice for any new projects, the way Python used to be. Before that, I come from a background in functional programming (and still find functional programming to be my favorite paradigm).

It seems to me that there are two disjoint sets of people: those who write Go regularly, and those who complain about generics in Go.

Of course, you can interpret this either way you wish!

1) Perhaps those latter people would like Go despite its lack of generics if they only bothered to get familiar with idiomatic Go.

2) Perhaps the lack of generics is precisely what prevents them from writing Go on a daily basis.

But as someone who actually does write Go on a daily basis, and has for a year and a half, I can honestly say that I've only ever missed them a handful of times. And I say this as a functional programmer who is used to being able to call "map" everywhere.

In fact, if I had to prioritize the things that I wish I could change about Go, generics would not be in the top three - not even in the top five[0]. They're just really something that I don't miss anymore.

[0] I could tell you what they are, but that'd be making it too easy - give Go a shot, long enough to realize you really don't need generics as much as you think you do, and then you'll probably have a good idea of the good, bad, and ugly when it comes to Go.

burntsushi5• 13 years ago

Just wanted to chime in and affirm your experience. I also love functional programming and have used Haskell for several projects (and will continue to do so). But I also use and love Go.

Like you, I've bumped up against areas where some form of generics beyond structural subtyping would have helped me solve a problem more elegantly. But it's never been a huge issue.

I think the primary reason why I'm drawn to Go is that I perceive it to be incredibly simple (like, Lua simple). Not just the language design, but the entire ecosystem---from idioms to tooling.

ekidd• 13 years ago

I've written several non-trivial Go programs, the most recent of which was a server that solved substitution ciphers (for use in subtitle OCR).

I tried to write nice idiomatic Go code. And I'm usually pretty good at adapting my brain to strange languages—I've positively enjoyed Haskell, constraint programming in Mozart, distributed functional programming in Elixir, and quite a few other strange things. (To be fair, I never did get comfortable in Prolog.)

And try as I might, every time I write a couple thousand lines of Go, I walk away in frustration. I love so much about the language, but my actual code keeps disappearing under the weight of error handlers, and stupid little iteration/transformation functions that I have to write over and over again thanks to the lack of generics. (Sometimes I get lucky, and an interface fits well.)

This means that every time I wander down a wrong path (and it's possible to wander down quite a few when messing with OCR algorithms), I end up having to tear up more code than I'd like. It's not fun.

Every time I say this, Go programmers say something like, give Go a shot, long enough to realize you really don't need generics as much as you think you do. But after three serious attempts, it's clear that the programs in my head were never meant to be implemented in Go. Which is too bad: It's a nice language in so many ways.

MetaCosm5• 13 years ago

I have OCR in production live written in pure Go. It does OCR on small specific portions of images to get keywords out to be put into a DB (1B+ page scans). We use tesseract for full page scans (when needed, when our OCR fails). But Go was so easy to write, and so fast to get live for small page partials that we wrote it in a few weeks (idea to live, just implementing well known algorithms) to avoid having to deal with tesseract overhead in the average case.

I am curious about specifically where you got bound up -- and how we managed to via ignorance or blind luck avoid these rough patches. Additionally, I am not 100% sure I understand why you refactor cycle is so brutal. That generally is one of the things I enjoy about Go, lightspeed refactor / dev / test cycles.

Good thing no one is asking you to use Go, Haskell is always around (and Elixir, I guess... I am too used to Erlang syntax, Elixir feels like an ill fitting glove) and we need lots of great languages -- and they SHOULD feel different and some shouldn't be a great fit for you.

mwsherman• 13 years ago

^ This is the right way to critique a language: here’s my experience, here’s what frustrated me, and most importantly, the humility to say that the problem comes down to a mismatch between mental model and implementation tool. More like this please.

MetaCosm5• 13 years ago

Agreed (Gopher 1+ years)! My heart still leans towards Erlang, but Go is my current daily driver. The vicious pragmatism at every turn is whats keeps me (and the team) loving it.

It isn't the most elegant, not even close. It isn't the most succinct, not even in the running. It isn't the most flexible -- people would mock you for claiming it is. It isn't interesting in the least, remarkably unremarkable as they say.

But when it comes to just simply getting shit done, and quickly understanding and being able to work in other peoples code, it is second to none. It just doesn't get in your way, and out of the box it gives you simple syntax, great tools and easy deploys.

cgislason• 13 years ago

How would you recommend becoming familiar with idiomatic Go?

I've read various articles including (but not limited to) tutorials, made a point of exploring a few open source projects and I've written a few thousand lines of Go. I enjoy writing Go, but I have a hard time so far figuring out if what I write is idiomatic.

burntsushi5• 13 years ago

Effective Go: http://golang.org/doc/effective_go.html

Short of that, read the source of some standard library packages. They are quite approachable.

mseepgood2• 13 years ago

How would you recommend becoming familiar with idiomatic Go?

By reading the source code of the standard library. It's directly linked from the API documentation.

reality_czech• 13 years ago

I'm more interested in what Go might be like without whiners.

What Go Might Be Like With Generics

Related Stories