What Go Might Be Like With Generics • Hacker News Board

Re: What Go Might Be Like With Generics

#21

Post by burntsushi » Mon, Jan 20, 2014, 3:49 AM UTC

chimeracoder wrote: post #19

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 ge…

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.

Re: What Go Might Be Like With Generics

#22

Post by Sir_Cmpwn » Mon, Jan 20, 2014, 3:53 AM UTC

vectorpush wrote: post #20

Sir_Cmpwn wrote: post #6

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.

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 calli…

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.

Re: What Go Might Be Like With Generics

#23

Post by hueho » Mon, Jan 20, 2014, 4:07 AM UTC

smegel wrote: post #14

skybrian wrote: post #10

Earlier quoted context omitted.

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.

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

They changed how closures are implemented in Go 1.1

There is a comprehensive doc by Russ Cox that explains in detail: https://docs.google.com/document/d/1bMwCey-gmqZVTpRax-ESeVuZ...

Re: What Go Might Be Like With Generics

#24

Post by MetaCosm » Mon, Jan 20, 2014, 4:10 AM UTC

Sir_Cmpwn wrote: post #22

vectorpush wrote: post #20

Earlier quoted context omitted.

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 calli…

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…

It is opinionated (a more useful word than pretentious), and it is this way across many things. From style to directory structure to versioning of dependencies to generics. If you actually read the reasoning behind them, I think they are rather well defended by very smart people, but to each their own.

If you really have an issue with some of the very opinionated ideas that come to a large degree bundled with Go, that is fair. That is great even! It probably isn't a good fit for you. Which is fine, there are hundreds of other programming languages that work for you, most are the wild west.

For certain people (like myself) the sanity of Go is striking -- each decision is made for unremarkable and straightforward defensible reasons... a lot of them are community driven over personal preference... it is better for the herd (think: herd immunity) if everyone uses one style and everyone uses one layout... etc. It isn't about being "right" or "needed" by every person, it is about being consistent so you can move from project to project and focus on learning the code, not layout or style, just what the code does.

Go was designed from inside Google, with large teams in mind with many projects.

Re: What Go Might Be Like With Generics

#25

Post by ekidd » Mon, Jan 20, 2014, 4:13 AM UTC

chimeracoder wrote: post #19

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 ge…

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.

Re: What Go Might Be Like With Generics

#26

Post by abofh » Mon, Jan 20, 2014, 4:14 AM UTC

Sir_Cmpwn wrote: post #22

vectorpush wrote: post #20

Earlier quoted context omitted.

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 calli…

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…

For what its worth, go the language doesn't force that structure. Go the tool does most of that. Most languages (in their pubescent state) don't have self-referential build tools, and so tools get added by third parties (make, scons, etc).

This is not a bad thing -- but it does mean that when a language chooses to ship "opinionated" tools as the default supporting toolset, users gain from the 'convention over code' as rails would call it - you run go build and the tool does the math -- but accomplishing source-tree validation across arbitrary maintainers trees is less trivial than "package-path == path" -- so if you name your code "com.foo.baz.bar", you'll be hurt by its opinions.

That said - if you want to learn the toolchain, 6c/6g/6l (and its 5/8 counterparts) will act like the simplest gcc tools - so long as the benefit you gain from manual definition outweighs the cost, you still win without "go build".

Re: What Go Might Be Like With Generics

#27

Post by burntsushi » Mon, Jan 20, 2014, 4:14 AM UTC

Sir_Cmpwn wrote: post #22

vectorpush wrote: post #20

Earlier quoted context omitted.

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 calli…

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…

> 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.

Symlinks solves this for me.

> 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.

AFAIK, `GOBIN` will allow you to relocate `bin`. I'm not aware of any such env var for `pkg`.

> This is an example of how Go as a language is pretentious.

It's not pretension. It's following a philosophy that prefers convention over configuration.[1]

[1] - http://golang.org/doc/articles/go_command.html#tmp_1

Re: What Go Might Be Like With Generics

#28

Post by kristianp » Mon, Jan 20, 2014, 4:15 AM UTC

skybrian wrote: post #10

Sir_Cmpwn wrote: post #6

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.

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.

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

Re: What Go Might Be Like With Generics

#29

Post by MetaCosm » Mon, Jan 20, 2014, 4:19 AM UTC

chimeracoder wrote: post #19

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 ge…

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.

Re: What Go Might Be Like With Generics

#30

Post by MetaCosm » Mon, Jan 20, 2014, 4:28 AM UTC

ekidd wrote: post #25

chimeracoder wrote: post #19

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 ge…

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…

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.