Gopher Tricks

http://talks.golang.org/2015/tricks.slide#1

by rjammala • 11 years ago

101 36 11 years ago

talks.golang.org

pluma• 11 years ago

I swear, one of these days I'll implement a gopher server and client in go just out of spite.

Every time I read a link mentioning "gopher" I expect it to be a neat hack based on the obsoleted protocol.

ruok0101• 11 years ago

Yes! Bring back gopher!

mindcrime2• 11 years ago

1a. Install Overbite (http://gopher.floodgap.com/overbite/)

1b. Install Lynx or eLinks

2. goto gopher://gopher.floodgap.com

mindcrime2• 11 years ago

I swear, one of these days I'll implement a gopher server and client in go just out of spite.

I've been playing around with Gopher a bit lately. I installed eLinks just to have a Gopher client. I've even been thinking about setting up gopher://gopher.fogbeam.com to serve content over Gopher protocol. :-)

Every time I read a link mentioning "gopher" I expect it to be a neat hack based on the obsoleted protocol.

Came here to say the same thing. Every time I see one of these headlines, I expect something about Gopher[1], not Golang.

[1] https://en.wikipedia.org/wiki/Gopher_(protocol)

digi_owl• 11 years ago

Reading over that article i find myself wondering if Gopher would be a good fit for a Freenet like system.

mseepgood• 11 years ago

By the author of the linked slide deck (Andrew Gerrand): https://github.com/nf/gogopherd/

By Brad Fitzpatrick (another Go team member): https://code.google.com/p/gogopherd/

0xdeadbeefbabe• 11 years ago

Also http://godoc.org/github.com/peterhellberg/gopher

fortytw2• 11 years ago

Saw an earlier version of this talk @ the Berlin Go meetup earlier this week - the exploration and explanation of `sync/atomic` by Andrew is really great

tshannon• 11 years ago

Well shit, how come I've never seen anonymous structs before.

That's pretty cool.

akhilcacharya• 11 years ago

Finding out Go had anonymous structs is what lead me to start learning Go.

apta• 11 years ago

What about finding out it didn't have generics?

Manishearth• 11 years ago

This is incredibly trippy :D

http://talks.golang.org/2015/tricks.slide#16

bsaul2• 11 years ago

I thought this kind of magic code was explicitly what go creators didn't want.

If i compare to Objective-C "object respondsToSelector:selector()" or "object isKindOfClass" equivalent, this go "casting to an anonymous struct" code seems extremely convoluted.

Plus, i may be wrong, but it seems like it's really not robust. You're trying to cast to an anonymous struct declared locally, that isn't linked to any other interface anywhere, and only implements part of the methods defined in the File struct. It's looks to me just as robust as using strings. What you would like to express, is what's in the comment : aka, test against something related to the File struct/interface.

eloff• 11 years ago

There are no anonymous structs in that slide, just anonymous interfaces.

johansch2• 11 years ago

I get the feeling the Go language creators defined the Go language syntax in many cases so that it explicitly looks different than the corresponding C syntax. Why?

(Yes, I know Rob's and Ken's history with regards to C.)

frou_dh3• 11 years ago

Lucky for you there's an article explaining exactly that: http://blog.golang.org/gos-declaration-syntax

---

I like the map. Here's the rules for Conway's Game of Life as a nested map:

    var cgol = map[state]map[int]state{
        alive: {
            0: dead,
            1: dead,
            2: alive,
            3: alive,
            4: dead,
            5: dead,
            6: dead,
            7: dead,
            8: dead,
        },
        dead: {
            0: dead,
            1: dead,
            2: dead,
            3: alive,
            4: dead,
            5: dead,
            6: dead,
            7: dead,
            8: dead,
        },
    }

johansch2• 11 years ago

I read that as arrogance.

Before C, naturally no-one knew C.

Before Go though, tens of millions know C.

They are casually throwing away all of that familiarity in the name of elegance. I think this is what might mean that Go doesn't "win".

pekk• 11 years ago

That type declaration is easily as unreadable as any "pointer to function returning pointer" declaration in C.

XorNot• 11 years ago

In practice I've not found anonymous structs too useful. You end up being very verbose and then discover you'd have been better off with a named type anyway.

It'd be nice to have a shorthand which mixed the type definition and assignment into a single line so you could do something like:

S := { x int : 1, y int : 2 }

Or even

S:= { x := 1, y := 2 }

PuerkitoBio• 11 years ago

I use them extensively for test cases (`cases := []struct{...} { ... }`) as mentioned in the slides. Also sometimes to marshal/unmarshal one-off json or xml payloads.

ericbb5• 11 years ago

This trick fits more into the "prank" category.

    package main
    
    import "fmt"
    
    // <Add one short line of valid Go code here>
    
    func main() {
    	var n int = 1
    	fmt.Println(n)
    }
    
    Compiler: "prog.go:8: cannot use 1 (type int) as type int in assignment"

Here's a trick that I expected to work but doesn't. Would be interested to hear the rationale if anyone knows it.

    m := map[[]int]int{}

barsonme• 11 years ago

Here's a trick that I expected to work but doesn't. Would be interested to hear the rationale if anyone knows it.

Per the spec[0]:

    The comparison operators == and != must be fully defined for operands 
    of the key type; thus the key type must not be a function, map, or 
    slice. If the key type is an interface type, these comparison 
    operators must be defined for the dynamic key values; failure will 
    cause a run-time panic.

[0] - https://golang.org/ref/spec#Map_types

ericbb5• 11 years ago

By "rationale" I was thinking more along the lines of "here is the reason we chose to do it this way" not just "here is the way we chose to do it".

shazow• 11 years ago

Here's a trick that I expected to work but doesn't. Would be interested to hear the rationale if anyone knows it.

    m := map[[]int]int{}

... will not work, because []int is a slice—that is, a pointer to an array of undetermined state (also technically some more metadata like an offset/size). Think of a slice as a "view" into an array, which does not necessarily need to remain static. A slice does not necessarily "own" the data it's providing a view of; you can have many slices of one array.

    m := map[[3]int]int{}

will work, because [3]int is an actual array.

To recap:

    a := [3]int{1,2,3}  // Array
    b := a[:2]          // Slice
    var c []int = a[:]  // Slice
    var d [3]int        // Array
    copy(d[:], c)       // Copy to (a slice of an) array from slice

ericbb5• 11 years ago

Well, you could take the position that types that permit modification should not be allowed as keys but then you would not allow arrays as keys, which Go does allow. Check this out: http://play.golang.org/p/kocW1BjTco

Another approach to take, which I think could be quite useful, is that if you use something modifiable as a key, then the map takes a snapshot of it when you perform the insert. That way, I can go and modify the key after the insert and any time thereafter if I look for the same sequence of integers, the map will find the associated value.

The problem here is that, in a language like Go, where pointer values are significant (contrast with Haskell, where two lists allocated separately but having the same contents are indistinguishable), you sometimes want to use pointer identity as the key so maybe it's hard to have it both ways.

Oh well. It's just something that surprises someone like me, who has grown accustomed to more value-oriented languages.

taralx• 11 years ago

I'm sure I'm not the only one, so could you explain the prank? Certainly the message you posted doesn't show up when I try to compile it...

ericbb5• 11 years ago

I was thinking that some people would want to figure it out for themselves so I didn't want to spoil the challenge for them... I kind of hoped someone else would post the solution.

Anyway, here is a solution: http://play.golang.org/p/Mg8x7sJ-hR

In other words, just insert the following line:

    type int string

The thing is, "int" is not a reserved word in Go. It's just a predeclared binding. You can rebind it -- even use "int" as a local variable name, like so: http://play.golang.org/p/0_iTzkg-5m

There are other interesting cases. For example,

    var true = false // Perfectly valid Go code!

I think of it as a prank because you could sneak such a line into somebody's code and the compiler would not help them realize what had happened, it would just complain about a lot of nonsense like 1 not being an int. In the "var true = false" example, there would not even be a compiler error, you'd just get baffling runtime errors.

For a list of all the predeclared identifiers, see here: http://golang.org/ref/spec#Predeclared_identifiers

Gopher Tricks

Related Stories