4 ms·

I understand what you mean by your quote. I will give you a toy example, then show the single example I have from Go, and ask if you know of any more. Toy exa

I understand what you mean by your quote. I will give you a toy example, then show the single example I have from Go, and ask if you know of any more. Toy example, a language that is simpler than possible: - If a language does not have functions, you must copy and paste the code every time you call it. Such a language would be "simpler than possible". The only example I know from Go: - Many people feel that the lack of generic functions can be solved similarly - such as copying and pasting code or doing search/replace - but makes the language "simpler than possible". (in the exact sense you mean.) (A generic function is one that works on different types without knowing what they are when it is written, or similar behavior.) So I've given you a single real example. But it's the only one I can think of. Other than this example, can you list the ways in which you feel it's "simpler than possible" or went "too far"? I would really appreciate if you could be specific.

omaranto 9y ago
I'll repeat my usual comment about what I found annoying in Go: It seems like strings are basically the only data type of unlimited size that is supported as map keys (or at least that seemed to be the case a few years ago). I think that only types for which equality is defined in the language could be used as keys. Those types where numbers, characters and all other "small" fixed-size types, structs all of those members had equality defined, arrays of a type with equality, and strings. The size of an array is part of the type, so in that list of types with equality the only source of unlimited sizedness are strings. I guess that cover most cases where you want a type of unknown size as a key, but I found it pretty annoying. If you want to use, say, polynomials with integer coefficients as keys in a map, you'd have to either choose a fixed maximum size (degree, for example, or number of monomials) for the polynomials or convert back and forth between strings. It's not the only language that forces you to convert things to strings and back for use as map keys (AWK and Lua come to mind), but I wish it didn't have that limitation.
- logicallee 9y ago
  thanks!
- burntsushi 9y ago
  You can actually dynamically generate struct types at runtime with the `reflect` package.[1] That might work for you. Not that I'm saying this is an ideal solution, I'm just giving you another option to evaluate. :-) (I suspect I'd sooner choose "serialize to a string" if I were in your shoes.) [1] - https://golang.org/pkg/reflect/#StructOf https://golang.org/pkg/reflect/#StructOf

omaranto 9y ago

I'll repeat my usual comment about what I found annoying in Go: It seems like strings are basically the only data type of unlimited size that is supported as map keys (or at least that seemed to be the case a few years ago). I think that only types for which equality is defined in the language could be used as keys. Those types where numbers, characters and all other "small" fixed-size types, structs all of those members had equality defined, arrays of a type with equality, and strings. The size of an array is part of the type, so in that list of types with equality the only source of unlimited sizedness are strings. I guess that cover most cases where you want a type of unknown size as a key, but I found it pretty annoying. If you want to use, say, polynomials with integer coefficients as keys in a map, you'd have to either choose a fixed maximum size (degree, for example, or number of monomials) for the polynomials or convert back and forth between strings. It's not the only language that forces you to convert things to strings and back for use as map keys (AWK and Lua come to mind), but I wish it didn't have that limitation.

logicallee 9y ago
thanks!
burntsushi 9y ago
You can actually dynamically generate struct types at runtime with the `reflect` package.[1] That might work for you. Not that I'm saying this is an ideal solution, I'm just giving you another option to evaluate. :-) (I suspect I'd sooner choose "serialize to a string" if I were in your shoes.) [1] - https://golang.org/pkg/reflect/#StructOf https://golang.org/pkg/reflect/#StructOf