Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Go Might Be Like With Generics

play.golang.org

Post reply on HN
Print view View original

41–49 of 49 posts

Re: What Go Might Be Like With Generics

#41

Post by MetaCosm »

Sir_Cmpwn wrote: post #35
MetaCosm wrote: post #24

Earlier quoted context omitted.

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, tha…

You make some good points, and I agree with most of them. The thing that troubles me is that Go seems like an exellent language for the most part. I really like it. That being said, it's unfortunate that in order to use it, I feel like some basic choices that I've come to expect as a programmer are taken from me.

Lots of things that are good for communities are restricting for individuals. Even more interesting, some of them lose significant value when anything less than a super-majority fall in line with them (This for example is why I think the Go community sometimes is very "passionate" about getting people on the right path, they are threatening the herd immunity of sane code and layout... one person goes off, others see their example and copy it... chaos!). I think the Go team was wise enough to see that the value of having sane baked in standards from day one FAR outweighed the complaints they knew would follow.

I think many people put too little value on communal norms, they have substantial value and are worth the adaption time. When in Windows C++ -- follow the conventions, when in Linux C -- again, follow the conventions -- and when in Go -- do that same. Fighting the dominant style for established platforms and languages is a mostly pointless, exhausting and sometimes debilitating task generally only done by those too inexperienced to realize how ridiculous it is. Team leads more experienced tend to just choose whatever is the dominate style / layout (preferably per-written up) for that platform/language realizing the benefits for getting ease of reading, consistency, hiring, firing, flexible labor (consultants) and most importantly not having absolutely worthless debates about style and layout.

Re: What Go Might Be Like With Generics

#42

Post by burntsushi »

Sir_Cmpwn wrote: post #37
abofh wrote: post #26

Earlier quoted context omitted.

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' a…

I like the idea of writing Go independently from the Go tool. Could you offer some brief insight into how dependency resolution might work, and link to some projects that break the mold?

Dependency resolution is done by the `go` tool automatically. If your project isn't compatible with the conventions established by the `go` tool, then it cannot infer your project's dependencies automatically.

I'm not aware of any projects that break the mold. Almost everyone that writes Go perceives the benefits of the `go` tool to be greater than the cons.

In another comment, I suggested using symlinks. I do it. Is there a reason why that doesn't work for you?

Re: What Go Might Be Like With Generics

#43

Post by burntsushi »

groovy2shoes wrote: post #33
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.

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

It seems like you disagree with Russ Cox.[1] Unfortunately, I'm not familiar enough with compilers to reconcile the disagreement. Any thoughts?

[1] - http://research.swtch.com/generic

Re: What Go Might Be Like With Generics

#44

Post by mseepgood »

cgislason wrote: post #34
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…

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.

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

Re: What Go Might Be Like With Generics

#45

Post by abofh »

Sir_Cmpwn wrote: post #37
abofh wrote: post #26

Earlier quoted context omitted.

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' a…

I like the idea of writing Go independently from the Go tool. Could you offer some brief insight into how dependency resolution might work, and link to some projects that break the mold?

it's been a while, but something approximating:

-- HN has eaten my asterisks, sed {asterisk} appropriately.

(locate your {5,6,8}{c,l,g} per your go install, or use 'go tool' if you want to go half-way in, I'll use go tool '6' (amd64) for reference).

go tool 6g {asterisk}.go

if you're linking to a final binary:

go tool 6l -o outname {asterisk}.6

Then run ./outname

I'm eliding over linking and includes, but if you run 'go tool 6l -help', you'll find all your expected 'include' and 'link' directory type parameters.

...

All of that aside, I've found it rare that I actively link go code to languages outside of C, and even then, only rarely do I need to share the C subset outside of the 'go' repo. So I'd step back for a second before you go down this road and ask _why_ it must conform. I assume you have a reason -- and if you have a reason and want go as well, exploring the nitty-gritty of 'go tool' is going to be a must. I found it easier to conform with go in a different repository - that may not be an option for you.

Re: What Go Might Be Like With Generics

#46

Post by Sir_Cmpwn »

abofh wrote: post #45
Sir_Cmpwn wrote: post #37

Earlier quoted context omitted.

I like the idea of writing Go independently from the Go tool. Could you offer some brief insight into how dependency resolution might work, and link to some projects that break the mold?

it's been a while, but something approximating: -- HN has eaten my asterisks, sed {asterisk} appropriately. (locate your {5,6,8}{c,l,g} per your go install, or use 'go tool' if you want to go half-way in, I'll use go tool '6' (amd64) for reference). go tool 6g {asterisk}.go if you're linking to a final binary: go tool 6l -o outname {asterisk}.6 Then run ./outname I'm eliding over linking and includes, but if you run…

One of the biggest "why" answers is software distribution. I distribute my code in source form and users expect to ./configure && make && make install. I feel like there's far too much manual intervention in "the Go way" that I'd be asking my non-Go-savvy users to embark upon.

Re: What Go Might Be Like With Generics

#48

Post by groovy2shoes »

burntsushi wrote: post #43
groovy2shoes wrote: post #33

Earlier quoted context omitted.

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

It seems like you disagree with Russ Cox.[1] Unfortunately, I'm not familiar enough with compilers to reconcile the disagreement. Any thoughts? [1] - http://research.swtch.com/generic

In this regard, C++ templates suffer from two problems. First, C++ templates are far more general than just generic types (in fact, they're Turing complete). Second, and the cause of lots of redundancy, is that C++ has no module system. C++ has no module system, and instead relies on the linker to provide functionality that could reasonably be provided at compile time given a sufficient module system. I'd say that generics in Go could avoid both of these problems: first by being just generics, and second by leveraging the module system.

Yes, generics will increase compile times. I seriously doubt it will increase compile times by an integer multiple, and most people probably won't even notice.

I'm not entirely sure what's going on that is causing the instruction cache to be underutilized, but it seems to me that the only way to avoid it is to also avoid abstraction in general. As usual, there's a tradeoff between performance and maintainability -- that's nothing new. Pick the appropriate abstractions for your use case.

Russ Cox is wrong in this case because his sample consists of one language: C++. Go is not C++, so it's a mistake to assume it will suffer from the same problems.

To get an idea of how generics could be reasonably implemented, take the Clay programming language as an example: http://claylabs.com/clay/

Re: What Go Might Be Like With Generics

#49

Post by skybrian »

groovy2shoes wrote: post #33
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.

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

You're assuming Go programmers will just write out the duplicate code rather than exploring alternatives. This doesn't seem to be what actually happens. Code written in Go isn't as concise as some languages, but it seems to have more to do with error-checking. I suspect we aren't seeing it because built-in types like slices and maps are already generic and people tend not to use fancier collections unless they're really needed.
Post reply on HN