4 ms·
I don't see anything about interface{} on https://godoc.org/compress/gzip https://godoc.org/compress/gzip , only byte slices, io.Reader and io.Writer.
by ptman 9y ago
I don't see anything about interface{} on https://godoc.org/compress/gzip https://godoc.org/compress/gzip , only byte slices, io.Reader and io.Writer.
- laumars 9y ago[deleted]
- jerf 9y ago"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 9y ago[deleted]
- jerf 9y ago"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 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.)
- deleted 9y ago[deleted]
- warent 9y agoThis is correct. I think part of what you're saying, in fewer words, is that there are interface method signatures, and there are interface expressions, which are ultimately different.
- PopsiclePete 9y ago>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.
- laumars 9y ago> With this statement, you've shown you have close to 0 Go experience. With that statement you've shown yourself to be an arrogant dick so I stopped reading. Maybe when you're in the mood to play nice I'll link you to some of the stuff I've written in Go over the last 6 years. Some of them are pretty cool - if I do say so myself - and definitely not beginner projects. For what it's worth, we all have the occasional blind spot when it comes to semantics. Including yourself. So there's no need to be an arrogant dick the few occasions you happen to be in the right.
- warent 9y agoWhen having an off-day, I find it's sometimes best to pause before saying something. The irony of this comment is really unfortunate
- laumars 9y agoYeah, it is unfortunate. My ranting was born from frustration that HN used to be a refuge from the usual pointless egotistical jibes as seen on other forums and social platforms. But over the years the quality of counterarguments has slowly been lowering to the level where it's now commonplace for people to make judgemental remarks about a persons ability based solely on a solitary semantical error (I obviously get the distinction between the two - I just wasn't aware they were described differently in literature). I have amassed a large body of real world projects under my belt over the last 3 decades and have used Go for 6 of those years. I've written some pretty interesting stuff in Go like file systems compiled against FUSE and compilers. Yet I by no means consider myself an expert in anything - least of all Go - as to do so would imply I'm not open to learning something new (even basic things I somehow missed during my initial studies). Despite that I still find it highly offensive and unnecessary for someone who knows nothing about me to say "you have close to 0 Go experience." when I've clearly demonstrated and described various Go-isms prior to his or her remark. Edit: weirdly I've got more down votes for this comment than my last one. I guess some people think rudeness is acceptable. Sad times.