Reassign an interface or allow GC to do its work on temporary variables

I'm very new to Go and am currently porting a PHP program.

I understand that Go is not a dynamically-typed language and I like that about it. It seems very structured and easy to keep track of everything.

But I've been coming across situations that seem to be a little ... ugly. Is there a better way of performing this sort of process:

plyr := builder.matchDetails.plyr[i]
plyrDetails := strings.Split(plyr, ",")
details := map[string]interface{}{
	"position": plyrDetails[0], "id": plyrDetails[1],
	"xStart": plyrDetails[2], "zStart": plyrDetails[3],
} 

EDIT:

Is there a better way to achieve a map containing the strings from plyr than to create two additional variables, to be destroyed straight afterwards? Or is this the correct way?

Go is NOT PHP. Write Go programs in Go. Write PHP programs in PHP.

> Interface values are represented as a two-word pair giving a pointer
> to information about the type stored in the interface and a pointer to
> the associated data. Go Data Structures:
> Interfaces

Reusing Go interface variables to "increase performance" makes no sense.

tl;dr:

• If possible, choose a different format and let a library do the string parsing/generation for you
• Use structs rather than maps for anything you use a few times, for more compiler checks
• The common way of using encoding/json accomplishes both of those.

Meanwhile, don't sweat perf too much because you'll probably vastly improve the old app's speed regardless; there's no indication speed of parsing or GC is a problem yet; and the syntactical differences you mentioned in the first rev. of the post don't necessarily actually relate to GC.

So, I understand you may be porting piece-for-piece, and that may limit what you can change now.

But if/when you can change things, a really clean solution would be to use the encoding/json package and a struct: the json package will parse input/generate output from structs without any manual string manipulation on your part, and using a struct gives you compile-time checking rather than only the runtime checking you get with a map. Lots of Go apps (and others) use JSON to expose their services.

An intermediate step could be to introduce struct types for any internal structure you use at least a few times, rather than maps, so even without updating the parsing, at least the internals of the app get the benefits of compile-time checking. structs are also what things like the gorm object/relational mapper expect to deal with. They happen to use less memory than maps, and be quicker (and more concise syntactically) to access, but those aren't even necessarily the most important considerations here.

On the performance of what you have now, and particularly whether different syntax would make it faster: don't sweat that, for a bunch of reasons: the port's likely to be faster than the PHP was whatever you do; we don't yet have any indication that parsing or GC is actually slow or your bottleneck; and the syntactical differences you talked about in the first revision of your question may not relate to GC much or at all. More/fewer var names in your code may not correspond to more/fewer heap allocations, 'cause often Go can allocate on the stack, briefly discussed under 'escape analysis' in Dave Cheney's Gocon Tokyo slides. And as peterSO said, we seem to be looking at allocations of smallish references, not, say, copying all of the string bytes from the request each time.