[zaarn]

>- No generics just mean you're going to be handing interface{} all the way in your stack, it makes things more complex and less readable for no reason (and less safe)

Depends on what you do. I've written a good chunk of go code and interface{} is the rare exception rather than the rule, usually employed where a user might supply arbitrary types (ie a unmarshaljson like function)

But if you do a website or webapp, 99% of your code is not using interface{} in it's methods.

>- error handling which is essentially string-based, in 2017? Give me a type system, please

You can put anything behind an error:

    type IntErr uint64
    func (i IntErr) Error() string {
        return strvonc.Atoi(i)
    }

The string is only present when you either use the stdlib errors or you output an error.

Additionally, nothing in Go forces you to actually use the error interface (sans stdlib).

You can invent your own Error interface that uses ints. (Won't work with most external libraries but nothing is stopping you)

Panic and Recover can to my knowledge both handle things that aren't errors; recover returns a interface{} that you check for value and type. You can put anything in there.

>stability: the language itself is fine on that, but the ecosystem really isn't.

A lot of projects focus on stability. If the API is breaking a lot they usually use Gopherpit or gopkg.in to ensure compatibility in the future.

In my experience, breaking the API is not something well used libraries do lightly (libraries with no or little use do break it sometimes since they lack the usage to refine it)

If you need more, you can use vendoring.

[laumars]

> But if you do a website or webapp, 99% of your code is not using interface{} in it's methods.

That's not really true. If you want an SQL database to back your website, then you'll deal with interface{} with Go's sql package. If you want to gzip your output, then you'll use interface{} with your writer.

To be fair, I think interface{} gets an almost unfair amount of hate. While it is fscking annoying when passing around core types (I hate having to use switch clauses just to inspect the type of an interface{}!!!) I do love how interface{} is used for complex structures. In fact there are a few areas of Go's standard library which I wish used interface{} more in that respect (eg Go's `file` struct should be an interface{} so I can create custom methods for os.Stdin/out/err)

[ptman]

I don't see anything about interface{} on https://godoc.org/compress/gzip , only byte slices, io.Reader and io.Writer.

[laumars]

[deleted]

[jerf]

"io.Reader and Writer are interface{}'s[1]."

No, they are interfaces, but they are not interface{}s, the interface that is met by having no methods and is therefore met by everything. Nobody is complaining about the use of interfaces that declare a useful set of methods, and are meant to be used when the set of methods is all the target code cares about. They may complain about some of the edges around them (no support for contra- or covariance), but that's not the complaint that is being discussed here.

The complaint is specifically around interface{}, which is a type that means nothing, and so everything fits into it. It means that if you are a function that is receiving an interface{}, you know nothing about the argument to start with, and will have to either pass it along to something else, or examine it via type assertions or in the worst case, the reflect library.

As a multi-year Go programmer, I agree that A: the "true" interface{} that is the meaningless type appears less often than people think, and that if you program is shot through with it, you are either working in a domain where Go is not suitable (complicated math processing, IMHO, for instance), or you are programming some other language in Go, and need to learn how to use Go properly, but also, B: it does happen that things that would be well-typed in other languages will have interface{} show up, which means you're going to sacrifice runtime safety and some performance, though the exact impact depends on what you are doing.

(I say the "true" interface{} because there's also some places where interface{} shows up, but it doesn't hurt you. For instance, the standard JSON library accepts an interface{} to say what data structure to parse the JSON into, and the code that implements that is somewhat complicated, but for the most part, that interface{} doesn't bother you, the Go user. In theory you can encounter run time errors if you pass in something that doesn't work, but in practice, if you pass in the same type every time, which is the natural case that is going to result if you just program normally, it's not a problem. In general, `interface{}` showing up in the incoming parameters of a library is much less concerning than an interface{} showing up in the return parameters for a library. In the former case, even though the language does not enforce type safety, you can enforce type safety by how you use the method; in the latter, you are stuck with an interface{} in your code with all that implies.)

[laumars]

[deleted]

[jerf]

"io.Reader is literally an interface{} though. I think what you're referring to is the other packages that define their own Reader's, ie using structs with methods, those are referred to as interfaces despite not literally being an interface{}."

That appears to be a definition unique to you that I have never seen from anyone else before, including the Go designers. io.Reader is an interface, no braces. Its full expansion would be interface { Read(p []byte) (n int, err error) }, and it is incorrect to substitute that for interface{} as that is a very different thing. Structs that implement the interface are, well, structs that implement the interface. interface{} is specifically reserved for discussion about the empty interface.

For instance, do a browser find for "interface" in https://golang.org/doc/effective_go.html ; you will find the documentation frequently referring to "interfaces" and that interface{} is reserved for the empty interface.

For the final proof of this, note how confusing it is for you to be reading the Go criticism as being about the use of interfaces-in-general in Go. Why would that provoke such a reaction? The answer is that people aren't talking about the feature, they are specifically referring to the number of places interface{} appears, the "Any" type, the "I don't know what's in there at all" type. It's not the use of interfaces in general, it's the way that suddenly one goes from a decent enough statically-typed language to a not-all-that-great dynamically-typed language when interface{} appears. (I disagree with the HN gestalt about the severity of this problem, but I understand it and still agree it's a non-zero problem.)

[PopsiclePete]

>io.Reader and Writer are interface{}'s[1].

With this statement, you've shown you have close to 0 Go experience.

* interace{} - a place-holder for a value of "any type". It means "a value that satisfies the empty interface", i.e. an interface with no methods. All types implement it. To do anything with the actual data it encapsulates, you have to do a type assertion to unbox the value. The type assertion will panic or return an error if the type assertion is incorrect. This is something like C's void , or Java's Object.

io.Reader, io.Writer - these are interface types that specify a set of methods that must be implemented by another type in order to satisfy that interface. These are akin to C#/Java's interfaces, but are less restrictive in the sense that any type in Go can implement them, not just "classes". E.g., http.HandlerFunc - a function type that implements the http.Handler interface.

[wybiral]

> That's not really true. If you want an SQL database to back your website, then you'll deal with interface{} with Go's sql package.

True. But for most real world scenarios I only ever use interfaces at the boundaries between APIs and they quickly get asserted into a type after being passed.

Conceptually they're a bit like passing marshalled data between APIs in that sense.

[leetrout]

> Conceptually they're a bit like passing marshalled data between APIs in that sense.

That's IMHO a great way to think about when it's Good™ to use them. Yes, there are times when you just have to use the empty interface type but it's really not as bad as everyone makes it out to be.

I love Go because it is explicit and because explicit types make everything easier in the long run. I get tired of seeing Go written like Python/Ruby/$otherDynamicLang with overuse of interface{} and/or reflect.

[drdaeman]

> But if you do a website or webapp, 99% of your code is not using interface{} in it's methods.

How do you deal with the lack of sets and trees? I believe those two data structures are frequently almost indispensable - even in the most boring mostly-CRUD web projects. And it's either type assertions on {}interfaces or go-generate based specialized implementations. Both feel odd to me. (Am I missing something?)

[zaarn]

For Sets, you can get away with the language slices and maps, which work sufficiently well.

I haven't found a need for trees in most of my projects and where I did I implemented it when necessary.

You can however, if you need to, separate the code and data of a tree by using a data adapter. The tree only stores a unique ID for an object which you can receive using the adapter, which would be a simple map or slice.

But as mentioned, I very very rarely needed them and not yet in any CRUD web project.