

Gopher Tricks - rjammala
http://talks.golang.org/2015/tricks.slide#1

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

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

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

~~~
0xdeadbeefbabe
Also
[http://godoc.org/github.com/peterhellberg/gopher](http://godoc.org/github.com/peterhellberg/gopher)

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

------
johansch
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_dh
Lucky for you there's an article explaining exactly that:
[http://blog.golang.org/gos-declaration-syntax](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,
            },
        }

~~~
johansch
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".

~~~
frou_dh
For someone who can already program, such things are trivial to learn.

If you class doing basic design work and taking time to document it as
"arrogance" then I'm afraid you may be suffering from negative mindset.

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

That's pretty cool.

~~~
akhilcacharya
Finding out Go _had_ anonymous structs is what lead me to start learning Go.

~~~
apta
What about finding out it didn't have generics?

------
ericbb
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{}

~~~
shazow
> 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

~~~
ericbb
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](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.

------
Manishearth
This is incredibly trippy :D

[http://talks.golang.org/2015/tricks.slide#16](http://talks.golang.org/2015/tricks.slide#16)

~~~
bsaul
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
There are no anonymous structs in that slide, just anonymous interfaces.

~~~
bsaul
Indeed, i think my point still hold though

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

