Thanks! That clarifies a few things. Too bad this isn't covered in the blog post which was specifically about how Go implements maps efficiently. Here are two interesting things the post doesn't cover:

1) How the insert works and why it's this way instead of any other;

2) Apparently the runtime has specialized implementations to insert values for some key types (string in this case), which implies it does in fact have multiple implementations of the "same" code.

Edit: I'm also curious how plain Go code can assign a value directly to an unsafe pointer without expressing the type? Or is that made unnecessary because the compiler rewrites the `myMap["key"] = value` step and has free reign to output unsafe, untyped Go code that isn't normally valid?

yeah. my guess is the compiler just outputs its intermediate format when it sees map assignment and can just do whatever it wants.

for reference you can play around with this by doing:

    go build test.go
    go tool objdump ./test

then search for test.go in the output and you should be able to find the go 'assembly' for your functions. also, if you use a big enough struct type then go will call into a memcpy() style routine to do the assignment.

    test.go:32            0x108d791               488d15d7170300          LEAQ go.string.*+255(SB), DX
    test.go:32            0x108d798               4889542410              MOVQ DX, 0x10(SP)
    test.go:32            0x108d79d               48c744241803000000      MOVQ $0x3, 0x18(SP)
    test.go:32            0x108d7a6               e835c2f7ff              CALL runtime.mapassign_faststr(SB)
    test.go:32            0x108d7ab               488b7c2420              MOVQ 0x20(SP), DI
    test.go:32            0x108d7b0               488d742430              LEAQ 0x30(SP), SI
    test.go:32            0x108d7b5               48896c24f0              MOVQ BP, -0x10(SP)
    test.go:32            0x108d7ba               488d6c24f0              LEAQ -0x10(SP), BP
    test.go:32            0x108d7bf               e83807fcff              CALL 0x104defc

0x104defc for me looks like it duffcopy from this file: https://golang.org/src/runtime/duff_amd64.s