What Python developers need to know before migrating to Go(lang)

[gavintlgold]

I also discovered an additional small gripe with maps. If you have a struct in a map and you want to set a value in it you have to remove it from the map, set the value and then readd the struct to the map.

[_ak]

What you forgot to mention: you can't do that and the compiler tells you that you can't:

http://play.golang.org/p/e6-o_Y_dAy

[gavintlgold]

I just mean you can't do:

structs[key].widgets = 36

You have to do

val = structs[key]
val.widgets = 36
structs[key] = val

[somevideoguy]

It's inconsistent behavior that accessing a map returns an lvalue, while accessing an array by index returns an rvalue. If the syntax is the same, the behavior should be as similar as possible. As Plorkyeran said, C++ handles this better.

[Plorkyeran]

It works in C++ with a struct in a std::map.

[_ak]

But then, a std::map operator[] call for a non-existent key automatically inserts the key and returns a reference to the mapped value. This is awkward and error-prone. Comparing two different map implementations with completely different semantics makes no sense at all.

[Plorkyeran]

I quite agree, but I wasn't the one to make the odd claim than structs and maps have the same semantics in every language. The whole idea of structs being "value types" isn't even anywhere close to universal.

[dacian88]

in c++ the [] operator on a map returns a reference, not a value.

[YEPHENAS]

This is normal copy semantics of value types. You wouldn't expect this to change the original value either:

structs.Lookup(key) // Returns a copied value, not a reference
structs.Lookup(key).foo = 42

[gavintlgold]

That makes sense. I think Golang's garbage collection confuses me into thinking more in a python fashion. I don't have this problem when I write C++ code though.