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.
Thread beginning with comment 552259
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 20:40 UTC in reply to "RE[2]: My thoughts on Go"
satsujinka
Member since:
2010-03-11

You don't need to know all the interfaces Example implements. You just have to know what the interface you're using requires and if your object has it.

In other words, you're looking at the code backwards compared to how Go works. Which may be an issue if ideal mental models of Go end up being backwards compared to other languages.

Reply Parent Score: 3

RE[4]: My thoughts on Go
by moondevil on Tue 12th Feb 2013 20:59 in reply to "RE[3]: My thoughts on Go"
moondevil Member since:
2005-07-08

You don't need to know all the interfaces Example implements. You just have to know what the interface you're using requires and if your object has it.


How do you do it without reading the full code that relates to Example struct, specially if it happens to be scattered across multiple files?

The solution proposed in multiple discussions in gonuts is to try to compile and see if it works and fix missing methods as required. Very helpful.

Reply Parent Score: 2

RE[5]: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 21:09 in reply to "RE[4]: My thoughts on Go"
satsujinka Member since:
2010-03-11

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

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

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.

Reply Parent Score: 2