4 ms·
Go is quite possibly the worst possible language for this example. You don't have generics, so the best you can do with an option type is return an interface {}
by jmgao 12y ago
Go is quite possibly the worst possible language for this example. You don't have generics, so the best you can do with an option type is return an interface {}, and any error checking you have to do has to be done manually. The problem is not that there is no way to do it properly in other languages (well, except lua), the problem is that the most natural way to do it is wrong.
- comex 12y agoI think this is too harsh. Out of the languages mentioned in the article, at least one (JavaScript) has no builtin lookup-or-throw method, and another (Ruby) requires a method call that's significantly uglier than the normal [] syntax, slightly discouraging its use. I don't know enough about the others (besides Python) to speak for them. In comparison, Go's multiple-return lookup thingy might be less natural/obvious than straight usage of foo[bar], but not by much.
- NateDad 12y agoGo has effectively built in option types - multiple returns... And almost every function that can fail uses them. That's what I was trying to say. No, you can't implement actual option types in any kind of reasonable way, but you don't need to.
- Dewie 12y ago> Go has effectively built in option types - multiple returns... They're more like a tuple than an Option type. An Option is a sum type, and a tuple type is a product type... and Option types are never represented as a product type (like tuple) in languages like Haskell, ML, etc. for a good reason. (Aside: why does Go have multiple returns, instead of just using tuples? Or just use structs? They could even call tuples "anonymous structs" if "tuple" is too academic...) Yes, I guess you meant that they can be used like an Option type, somewhat incidentally and indirectly.
- NateDad 12y agoGo doesn't have tuples because they aren't very compatible with compile-time type safety. You could using []interface{} as a tuple, but why would you? Go does have anonymous structs, they're just only of moderate use in a statically typed language (given that you need to specify the types for function arguments and return types) You can do something like this: // make a list of anonymous structs // often useful for table driven tests tests := []struct{ Name string, count int }{ { Name: "First test", Count: 5 }, { Name: "Second test", Count: 7 } } for _, test := range tests { if test.Count > 5 { t.Errorf("%s: expected <= 5, got %d", test.Name, test.Count) } }
- Dewie 12y ago> Go doesn't have tuples because they aren't very compatible with compile-time type safety. What's the problem? Couldn't you have something like: (string, int) For example in the return type of a function? I.e., this function returns a tuple of string and int.
- NateDad 12y agoWhat's the difference between that and multiple returns? You can have func foo() (string, int) func bar(a string, b int) And do bar(foo()) The only thing you couldn't do is make a slice of tuples... But you can make a slice of structs that have just a string and an int. I guess I just don't see a huge amount of utility that isn't otherwise already covered.