4 ms·

After working with it for a year, these are the things I don't like about Go: 1) No constructors. When I create a struct, without a constructor, I can't be 10

After working with it for a year, these are the things I don't like about Go: 1) No constructors. When I create a struct, without a constructor, I can't be 100% if certain fields are populated or not. With a constructor, I could force this. With a large number of people working on a code base, you can't assume anything, unfortunately, but without a constructor to force exact data in a struct, it makes it more tedious to be sure. 2) Error handling is ugly and tedious. Not being able to get the type of an error makes it a lot more inconvenient. At least in our codebase, errors are almost string parsing, it's ridiculous. 3) Nil map vs empty map is a very strange thing to keep in the code. Why even allow this distinction? 4) Named return parameters are really stupid. This is another thing that doesn't fit the philosophy of what I understand Go to be. It forces a bunch of verbose opinionated rules on us, but then allows named return parameters which causes confusion. 5) It's very hard to tell the difference between package names vs structs. Luckily Gogland allows you to change the color for package names so this helps me out tremendously, but there should be a better way to differentiate without relying on your IDE. Overall it's okay but nowhere near perfect and has some really weird deficiencies. The company I work for uses Go with dependency injection which I hate and I think is very ugly but a paycheck is a paycheck.

camus2 9y ago
> 4) Named return parameters are really stupid. This is another thing that doesn't fit the philosophy of what I understand Go to be. It forces a bunch of verbose opinionated rules on us, but then allows named return parameters which causes confusion. They exist because go really has exceptions. The only way to "catch" and modify variables in the "catch" before they are returned is to use named return values. You can't return anything from a panic/defer/recover directly. Error as value are just a convention. https://play.golang.org/p/gRoUaVUs8M https://play.golang.org/p/gRoUaVUs8M
- barsonme 9y ago
  They also help clarify what the return parameters are. It can be helpful if you have multiple if the same type (e.g., func Foo() (int, int))
greenhouse_gas 9y ago
>No constructors You can create a function which makes (and populates) the struct. For example, https://play.golang.com/p/rvSvEZNkXe https://play.golang.com/p/rvSvEZNkXe >Error handling is ugly and tedious. Not being able to get the type of an error makes it a lot more inconvenient. See https://stackoverflow.com/a/7006853/5849285 https://stackoverflow.com/a/7006853/5849285 to switch on type (error is a interface with a Error func[1]), so you can define different error types [2], or use `int` to define error type. [1]: https://blog.golang.org/error-handling-and-go https://blog.golang.org/error-handling-and-go [2]: For example, os.Open returns a * PathError
alexdias 9y ago
1) The struct's fields will have the default value for their respective type. I understand you might want to force specific values, but if this is the case, maybe you could only export an interface to the struct? And said interface would have the "constructor" methods. 2) You can always encapsulate errors. Your code will still have a type assertion or switch, but you don't need to use string parsing (although I have seen string parsing used in libraries such as mgo - the MongoDB client library). 3) Because maps are references, just like slices. You can still call len() on a nil map and therefore treat it as an empty map? If you mean the assignment to nil maps: https://groups.google.com/forum/#!topic/golang-nuts/RkYIF8SqcXo https://groups.google.com/forum/#!topic/golang-nuts/RkYIF8Sq... 4) This is subjective I think, but I disagree. I like just being able to type "return" instead of for instance typing in 6 different places "return something, err". 5) Do you mean un-exported structs (and therefore lowercase)? I haven't come across this, but I can see where it could be an issue. I usually just use VSCode and mouse over to quickly see a name's definition. I agree with you that it's not perfect, but as I saw someone else say on the internet, it's the least bad language (in my opinion). And I don't envy you for working with dependency injection in Go :)
flukus 9y ago
> 1) No constructors. When I create a struct, without a constructor, I can't be 100% if certain fields are populated or not. With a constructor, I could force this. With a large number of people working on a code base, you can't assume anything, unfortunately, but without a constructor to force exact data in a struct, it makes it more tedious to be sure. Is there something similar to opaque types in c? Like a "constructor" function that returns an interface and then methods that operate on the interface instead of the struct itself? What I don't get about go is why certain trade offs were made, some work well for a systems language, like error codes, but then there are different trade offs that don't, like the GC. Similarly the GC makes sense for a high level apps language, but features like lacking generics don't.
tqkxzugoaupvwqr 9y ago
> 2) Error handling is ugly and tedious. Not being able to get the type of an error makes it a lot more inconvenient. At least in our codebase, errors are almost string parsing, it's ridiculous. You can make arbitrary types implement the error interface. Your custom error type can carry all the information you need. If err != nil you make a type assertion and access the error’s information. See [1]. [1] https://blog.golang.org/error-handling-and-go https://blog.golang.org/error-handling-and-go

camus2 9y ago

> 4) Named return parameters are really stupid. This is another thing that doesn't fit the philosophy of what I understand Go to be. It forces a bunch of verbose opinionated rules on us, but then allows named return parameters which causes confusion. They exist because go really has exceptions. The only way to "catch" and modify variables in the "catch" before they are returned is to use named return values. You can't return anything from a panic/defer/recover directly. Error as value are just a convention. https://play.golang.org/p/gRoUaVUs8M https://play.golang.org/p/gRoUaVUs8M

barsonme 9y ago
They also help clarify what the return parameters are. It can be helpful if you have multiple if the same type (e.g., func Foo() (int, int))

greenhouse_gas 9y ago

>No constructors You can create a function which makes (and populates) the struct. For example, https://play.golang.com/p/rvSvEZNkXe https://play.golang.com/p/rvSvEZNkXe >Error handling is ugly and tedious. Not being able to get the type of an error makes it a lot more inconvenient. See https://stackoverflow.com/a/7006853/5849285 https://stackoverflow.com/a/7006853/5849285 to switch on type (error is a interface with a Error func[1]), so you can define different error types [2], or use `int` to define error type. [1]: https://blog.golang.org/error-handling-and-go https://blog.golang.org/error-handling-and-go [2]: For example, os.Open returns a * PathError

alexdias 9y ago

1) The struct's fields will have the default value for their respective type. I understand you might want to force specific values, but if this is the case, maybe you could only export an interface to the struct? And said interface would have the "constructor" methods. 2) You can always encapsulate errors. Your code will still have a type assertion or switch, but you don't need to use string parsing (although I have seen string parsing used in libraries such as mgo - the MongoDB client library). 3) Because maps are references, just like slices. You can still call len() on a nil map and therefore treat it as an empty map? If you mean the assignment to nil maps: https://groups.google.com/forum/#!topic/golang-nuts/RkYIF8SqcXo https://groups.google.com/forum/#!topic/golang-nuts/RkYIF8Sq... 4) This is subjective I think, but I disagree. I like just being able to type "return" instead of for instance typing in 6 different places "return something, err". 5) Do you mean un-exported structs (and therefore lowercase)? I haven't come across this, but I can see where it could be an issue. I usually just use VSCode and mouse over to quickly see a name's definition. I agree with you that it's not perfect, but as I saw someone else say on the internet, it's the least bad language (in my opinion). And I don't envy you for working with dependency injection in Go :)

flukus 9y ago

> 1) No constructors. When I create a struct, without a constructor, I can't be 100% if certain fields are populated or not. With a constructor, I could force this. With a large number of people working on a code base, you can't assume anything, unfortunately, but without a constructor to force exact data in a struct, it makes it more tedious to be sure. Is there something similar to opaque types in c? Like a "constructor" function that returns an interface and then methods that operate on the interface instead of the struct itself? What I don't get about go is why certain trade offs were made, some work well for a systems language, like error codes, but then there are different trade offs that don't, like the GC. Similarly the GC makes sense for a high level apps language, but features like lacking generics don't.

tqkxzugoaupvwqr 9y ago

> 2) Error handling is ugly and tedious. Not being able to get the type of an error makes it a lot more inconvenient. At least in our codebase, errors are almost string parsing, it's ridiculous. You can make arbitrary types implement the error interface. Your custom error type can carry all the information you need. If err != nil you make a type assertion and access the error’s information. See [1]. [1] https://blog.golang.org/error-handling-and-go https://blog.golang.org/error-handling-and-go