Hacker News Reader

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/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 :)

>No constructors

You can create a function which makes (and populates) the struct.

For example, 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 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 [2]: For example, os.Open returns a * PathError

> 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

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))

> 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

> 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.