5 ms·

"Last week I decided to start going through some of the popular Go tutorials" I assure readers that this kind of problem is only faced by beginners. If the aut

by Jabbles 13y ago

"Last week I decided to start going through some of the popular Go tutorials" I assure readers that this kind of problem is only faced by beginners. If the author approached the problem from the other direction, i.e. by asking "how do I extract a file's contents?", he would have looked up the documentation for os.File, and found it had a Read() method. It's not often that you come across an arbitrary interface you have to implement, but aren't sure what to provide. If the documentation doesn't say, then presumably there's an type in the same package that you're meant to use. If not, domain-specific knowledge will help. In this case it's necessary to have a basic idea of the way the standard library works - which as a beginner, the author doesn't have. We rarely want a list of all possible types that can implement an interface. There are many different types that implement io.Reader in the standard library, it's not necessary for any particular package to be aware of all others ("slick"). And anyway, your editor might be able to help. http://golang.org/pkg/os/#File.Read http://golang.org/pkg/os/#File.Read

pjmlp 13y ago
> I assure readers that this kind of problem is only faced by beginners. No, this problem is faced by anyone that needs to read code code written by other developers. If you are faced by a code base written by a team of 30+ developers, good luck trying to find out which types implement which interface. At least LiteIDE (http://code.google.com/p/liteide http://code.google.com/p/liteide) is a possible help that eases the problem.
- tomp 13y ago
  I think this could mostly be solved by automatic documentation generation tools and/or IDEs. Just like Java IDEs and JavaDoc index the world and show relations (i.e. classes that implement an interface), so could (and probably will) Go tools do so.
  - pjmlp 13y ago
    Well at least it is not only Java requiring IDEs then. :)
    - Mr_T_ 13y ago
      People are programming in completely dynamic, duck typed languages and say that these languages are best without IDE.
      - pjmlp 13y ago
        Funny you say that, because the first IDEs were actually invented for dynamic languages (Smalltalk & Lisp).
- beshrkayali 13y ago
  Like the author, I had the same problem when I was going through the GO tutorial as well (I have to say it's not the greatest tutorial for someone coming from a totally different programming background, I've never done C or Java for example). Interface in GO can be a little bit tricky to understand at first, but then they become kind of like a nice way of thinking about coding. I can't help to think like what @tomp said. It's really up to the developers to annotate their code and document their Interfaces, specially when using a systems programming language like GO, comments are essential as the code is not as self-explanatory like Python or Ruby. GO provides an excellent tool to generate documentation from internal or external packages: http://golang.org/cmd/godoc/ http://golang.org/cmd/godoc/. There's this great write-up on GO's Interface by Jordan Orelli: http://jordanorelli.tumblr.com/post/32665860244/how-to-use-interfaces-in-go http://jordanorelli.tumblr.com/post/32665860244/how-to-use-i...
- mseepgood 13y ago
  > No, this problem is faced by anyone that needs to read code code written by other developers. No, it's not a problem for code readers. If you see a file being passed as an argument to a function which expects a Reader, you know that it implements Reader. Otherwise it wouldn't have compiled.
  - pjmlp 13y ago
    How to answer the question "Given type X what are ALL interfaces that it implements from the overall code"?
    - NateDad 13y ago
      First off, why do you need to know? The whole point is that interfaces are in no way tied to the things that implement them. Second, you can search for the function definition(s) that define the interface. Search for Write(p []byte) if you're looking for Writers. If you're in control of the interface, you can just modify it slightly and see what breaks.
      - pjmlp 13y ago
        Because in the enterprise world we have these boring projects with 60+ developers scattered around the world, high rotation of developers and new guys need to be able to jump into the code of several megabytes of text?
      - NateDad 13y ago
        You still haven't said why you would need to find all implementations of an interface. "Because I'm new to the company" is not a reason. The thing about interfaces is that the function that takes the interface is the thing that defines how it is used. The implementation of the type that implements the interface is irrelevant. log.Logger writes logging output to an io.Writer. It doesn't care what the implementation of any particular writer is... the writer could be sending data across the network, it could be writing it to the console, could be writing to a file... doesn't matter. Logger just calls Write() and merrily goes about its business. Trying to look up all the implementations of the io.Writer interface is not useful when looking at log.Logger. They're mostly unrelated. Now, if you're trying to figure out how to do some specific thing, like log to a Windows named pipe, then you'd want to start looking around your named pipe library to see if it implements Write().... which it almost certainly does.
nknighthb 13y ago
I find the author's particular problem utterly baffling from either direction. When presented with io.Reader's specification: type Reader interface { Read(p []byte) (n int, err error) } It should be obvious to any modestly experienced developer that an ordinary file object is likely to satisfy the requirement of having a common Read method. This seems like a basic failure to understand what a Go interface is, nevermind any understanding of the standard library.
- garethadams 13y ago
  I'm not a Go programmer, but this seems like implicit interfaces could bite you in the ass pretty easily. For example if I have a Book class that implements a Read method (to mark the book as having been read, for example) then have I just created something which implements io.Reader?
  - dsymonds 13y ago
    Only if you had a method with that exact signature: taking a []byte argument and returning an int and an error. You'd have to stretch to have that happen by chance.
    - garethadams 13y ago
      Ok, I did think that would be part of it but the only reference I could find in the documentation was at http://golang.org/doc/faq#overloading http://golang.org/doc/faq#overloading which suggested that names are the only thing considered. (The other document I looked at before was http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html which didn't help) Fair enough, I did say I was only speculating and I've learned something.
  - tjgq 13y ago
    Only if your Book.Read method has the same signature as Reader.Read (i.e., not just the same name).
  - mseepgood 13y ago
georgemcbay 13y ago
"I assure readers that this kind of problem is only faced by beginners" I disagree. I've even brought this up before in passing on HN: https://news.ycombinator.com/item?id=5639846 https://news.ycombinator.com/item?id=5639846 I've written many thousands of lines of Go code and have been using the language for more than a year and I still think the gist of the author's argument is a valid pain point when it comes to Go documentation. I'm now very familiar with the standard Go library, so the problem doesn't impact me as much as it used to, but I do find auto-generated Go documentation for new libraries I haven't yet used to be much harder to get a quick mental overview of than code autogenerated from other languages I've programmed in (including languages which are OO, functional or procedural). Go is still my favorite language to program in, but I think there is a valid issue here (one that can be fixed with improved tooling)
- MetaCosm 13y ago
  I am someone who has shipped code in many "less popular" languages (Erlang, Eiffel, Lisp...) and am currently exploring / building apps with Go. As someone with some actually time with Golang, could you elaborate on the pain point a bit? I had a similar issue on my first toy program with Golang, but found it trivial to check the implemented methods, or assign it and let the compiler blow up if it doesn't fulfill the needs.

by Jabbles 13y ago

pjmlp 13y ago

> I assure readers that this kind of problem is only faced by beginners. No, this problem is faced by anyone that needs to read code code written by other developers. If you are faced by a code base written by a team of 30+ developers, good luck trying to find out which types implement which interface. At least LiteIDE (http://code.google.com/p/liteide http://code.google.com/p/liteide) is a possible help that eases the problem.

tomp 13y ago
I think this could mostly be solved by automatic documentation generation tools and/or IDEs. Just like Java IDEs and JavaDoc index the world and show relations (i.e. classes that implement an interface), so could (and probably will) Go tools do so.
- pjmlp 13y ago
  Well at least it is not only Java requiring IDEs then. :)
  - Mr_T_ 13y ago
    People are programming in completely dynamic, duck typed languages and say that these languages are best without IDE.
    - pjmlp 13y ago
      Funny you say that, because the first IDEs were actually invented for dynamic languages (Smalltalk & Lisp).
beshrkayali 13y ago
Like the author, I had the same problem when I was going through the GO tutorial as well (I have to say it's not the greatest tutorial for someone coming from a totally different programming background, I've never done C or Java for example). Interface in GO can be a little bit tricky to understand at first, but then they become kind of like a nice way of thinking about coding. I can't help to think like what @tomp said. It's really up to the developers to annotate their code and document their Interfaces, specially when using a systems programming language like GO, comments are essential as the code is not as self-explanatory like Python or Ruby. GO provides an excellent tool to generate documentation from internal or external packages: http://golang.org/cmd/godoc/ http://golang.org/cmd/godoc/. There's this great write-up on GO's Interface by Jordan Orelli: http://jordanorelli.tumblr.com/post/32665860244/how-to-use-interfaces-in-go http://jordanorelli.tumblr.com/post/32665860244/how-to-use-i...
mseepgood 13y ago
> No, this problem is faced by anyone that needs to read code code written by other developers. No, it's not a problem for code readers. If you see a file being passed as an argument to a function which expects a Reader, you know that it implements Reader. Otherwise it wouldn't have compiled.
- pjmlp 13y ago
  How to answer the question "Given type X what are ALL interfaces that it implements from the overall code"?
  - NateDad 13y ago
    First off, why do you need to know? The whole point is that interfaces are in no way tied to the things that implement them. Second, you can search for the function definition(s) that define the interface. Search for Write(p []byte) if you're looking for Writers. If you're in control of the interface, you can just modify it slightly and see what breaks.
    - pjmlp 13y ago
      Because in the enterprise world we have these boring projects with 60+ developers scattered around the world, high rotation of developers and new guys need to be able to jump into the code of several megabytes of text?
    - NateDad 13y ago
      You still haven't said why you would need to find all implementations of an interface. "Because I'm new to the company" is not a reason. The thing about interfaces is that the function that takes the interface is the thing that defines how it is used. The implementation of the type that implements the interface is irrelevant. log.Logger writes logging output to an io.Writer. It doesn't care what the implementation of any particular writer is... the writer could be sending data across the network, it could be writing it to the console, could be writing to a file... doesn't matter. Logger just calls Write() and merrily goes about its business. Trying to look up all the implementations of the io.Writer interface is not useful when looking at log.Logger. They're mostly unrelated. Now, if you're trying to figure out how to do some specific thing, like log to a Windows named pipe, then you'd want to start looking around your named pipe library to see if it implements Write().... which it almost certainly does.

nknighthb 13y ago

I find the author's particular problem utterly baffling from either direction. When presented with io.Reader's specification: type Reader interface { Read(p []byte) (n int, err error) } It should be obvious to any modestly experienced developer that an ordinary file object is likely to satisfy the requirement of having a common Read method. This seems like a basic failure to understand what a Go interface is, nevermind any understanding of the standard library.

garethadams 13y ago
I'm not a Go programmer, but this seems like implicit interfaces could bite you in the ass pretty easily. For example if I have a Book class that implements a Read method (to mark the book as having been read, for example) then have I just created something which implements io.Reader?
- dsymonds 13y ago
  Only if you had a method with that exact signature: taking a []byte argument and returning an int and an error. You'd have to stretch to have that happen by chance.
  - garethadams 13y ago
    Ok, I did think that would be part of it but the only reference I could find in the documentation was at http://golang.org/doc/faq#overloading http://golang.org/doc/faq#overloading which suggested that names are the only thing considered. (The other document I looked at before was http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html which didn't help) Fair enough, I did say I was only speculating and I've learned something.
- tjgq 13y ago
  Only if your Book.Read method has the same signature as Reader.Read (i.e., not just the same name).
- mseepgood 13y ago

georgemcbay 13y ago

"I assure readers that this kind of problem is only faced by beginners" I disagree. I've even brought this up before in passing on HN: https://news.ycombinator.com/item?id=5639846 https://news.ycombinator.com/item?id=5639846 I've written many thousands of lines of Go code and have been using the language for more than a year and I still think the gist of the author's argument is a valid pain point when it comes to Go documentation. I'm now very familiar with the standard Go library, so the problem doesn't impact me as much as it used to, but I do find auto-generated Go documentation for new libraries I haven't yet used to be much harder to get a quick mental overview of than code autogenerated from other languages I've programmed in (including languages which are OO, functional or procedural). Go is still my favorite language to program in, but I think there is a valid issue here (one that can be fixed with improved tooling)

MetaCosm 13y ago
I am someone who has shipped code in many "less popular" languages (Erlang, Eiffel, Lisp...) and am currently exploring / building apps with Go. As someone with some actually time with Golang, could you elaborate on the pain point a bit? I had a similar issue on my first toy program with Golang, but found it trivial to check the implemented methods, or assign it and let the compiler blow up if it doesn't fulfill the needs.