Google Go: the good, the bad, and the meh
Linked by Thom Holwerda on Mon 11th Feb 2013 22:59 UTC
General Development "I feel like writing about the Go programming language (or 'Golang') today, so instead today's topic is computer stuff. For the record, the language I've programmed the most in has been Python, so that’s the perspective I'm analyzing it from." Some good and bad things about Go.
E-mail Print r 2   87 Comment(s) http://osne.ws/knv
Permalink for comment 552335
To read all comments associated with this story, please click here.
RE[6]: My thoughts on Go
by lucas_maximus on Wed 13th Feb 2013 16:35 UTC in reply to "RE[5]: My thoughts on Go"
lucas_maximus
Member since:
2009-08-18

All of Example's methods have to be in the same package as Example. Ideally, Example should be in its own package. Ideally, an object shouldn't require more than 1 file to specify. Ideally, there should be some documentation.

So bad architecture/design choices aside... There's no reason a grep can't take care of this, but it's usually just as fast to compile (and it gives better information.)


Bad architecture will always exists, this is because not all developers are created equal.

Besides, you don't have to read all the code. You can easily pick up Example's methods by scanning function declarations.


Or you can just look at the top of the file for something like "implements".

The design choice of inferring interfaces is a sound one. It allows you to add/remove/restructure interfaces without having to modify your objects. Yes, you have to remember more or get an IDE, but it makes life much easier, especially in the prototyping stages of development when interfaces aren't yet stable.


You do know how tools like rename work in IDEs don't you?

It makes this benefit moot.

Edited 2013-02-13 16:40 UTC

Reply Parent Score: 2