4 ms·
i've not had a ton of experience with Go, just some coder challenge type stuff, but i love almost everything about the language. it has the feel of old skool C,
by bkirkby 14y ago
i've not had a ton of experience with Go, just some coder challenge type stuff, but i love almost everything about the language. it has the feel of old skool C, but greatly improved and upgraded.
the one thing i hate about Go is how it does exported identifiers. in order to make a variable/method available to other packages, you must start the variable name with an uppercase letter. this is the only way to export identifiers which means the exporting is a bit obfuscated.
giving meaning to the first letter of a variable name is filled with potential problems:
1. people will inadvertently export properties simply because they chose to name them with uppercases
2. in some cases, you will need to force this case sensitive language to be case insensitive. ex: a json property named "address" needs to unmarshal into a Go variable named "Address"
3. i don't have this concern personally, but i wonder about coding in languages that don't have uppercases. (actually, it's prolly legit to force them to code in english i suppose)
i've read the Go engineers are extremely happy with this feature, so i guess i'm going to have to get used to it and the bevy of problems it creates if i'm going to continue using it.
- markdrago 14y agoFWIW the 'tag' concept in Go alleviates concern #2. Info regarding tags (scroll a bit): http://golang.org/ref/spec#Struct_types http://golang.org/ref/spec#Struct_types How tags are used by the built-in JSON encoding library: http://golang.org/pkg/encoding/json/#Marshal http://golang.org/pkg/encoding/json/#Marshal Of course, just because this kind of thing can be handled with tags doesn't mean that people will actually know to use them or actually use them correctly.
- bkirkby 14y agothanks for that! i wasn't even aware of field tags. i can see this solution causing other problems too. there can only be one tag per field, right? what happens when another library has a different meaning for the tag? are we going to see a hacky standard emerge where we have multiple tags in the one field separated by semicolons (with a precursor for each tag like 'json:')? it feels like an ugly hack to use tags this way, but i guess an ugly hack is what is needed for this right now. i would much prefer a separate keyword to explicitly export fields. or, since we are already hacking the tag, why not have the compiler export any field with a tag called "export"?