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

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

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)

OR

1b. Install Lynx or eLinks

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

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 }

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

---

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,
        },
    }

map[state]map[int]state -> a map of state keys pointing to maps of int keys pointing to states

    "map of int to string"
     map   [int]   string
    
    "map of state to map of int to state"
     map   [state]   map   [int]   state

( ...Any excuse to link to this excellent presentation: http://www.infoq.com/presentations/Simple-Made-Easy )

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

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.

I can barely read this: void (signal(int, void (fp)(int)))(int);

I can read this easily: func signal(int, func(int)) func(int)

That looks like a good deal to me! :)

That's pretty cool.

    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"

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

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

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

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

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.

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.

"Map lookup requires an equality operator, which slices do not implement. They don't implement equality because equality is not well defined on such types; there are multiple considerations involving shallow vs. deep comparison, pointer vs. value comparison, how to deal with recursive types, and so on. We may revisit this issue—and implementing equality for slices will not invalidate any existing programs—but without a clear idea of what equality of slices should mean, it was simpler to leave it out for now.

In Go 1, unlike prior releases, equality is defined for structs and arrays, so such types can be used as map keys. Slices still do not have a definition of equality, though."

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

In other words, just insert the following line:

    type int string

There are other interesting cases. For example,

    var true = false // Perfectly valid Go code!

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

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

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.