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 552263
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: My thoughts on Go
by satsujinka on Tue 12th Feb 2013 21:09 UTC 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

RE[6]: My thoughts on Go
by moondevil on Tue 12th Feb 2013 21:26 in reply to "RE[5]: My thoughts on Go"
moondevil Member since:
2005-07-08

You sound like you never did code development on enterprise level reading code developed by people all across the world.

Those advices only work if you're developing on your own or a very small set of developers.

Reply Parent Score: 2

RE[7]: My thoughts on Go
by siride on Wed 13th Feb 2013 04:18 in reply to "RE[6]: My thoughts on Go"
siride Member since:
2006-01-02

Exactly. These people who say that IDEs are useless have never really used them, nor worked on very large projects.

Sure, you can do most everything you can do in an IDE without an IDE. And you can write assembly instead of C, or machine language in a hex editor if you want to. You can use Perl scripts to spelunk through code and produce static reference listings. If you want to...

But I want to get work done. And I like being able to jump around my code with keyboard shortcuts that are only made possible because the editor/tool I'm using actually understands the structure of my project and the language I'm coding in (beyond basic syntax highlighting). And I like being able to step through code while looking at the project in the same tool I develop it in, instead of using esoteric commands in a command line-only tool that show you very little context at any given point in time. Sure, you can do it...but why when there are better tools? Use the right tool for the job.

Reply Parent Score: 2

RE[7]: My thoughts on Go
by satsujinka on Wed 13th Feb 2013 10:14 in reply to "RE[6]: My thoughts on Go"
satsujinka Member since:
2010-03-11

On the contrary that's exactly what I get paid for.

I would appreciate it if you don't try to undermine my credibility when all I've done is answer your questions.

Reply Parent Score: 2

RE[6]: My thoughts on Go
by lucas_maximus on Wed 13th Feb 2013 16:35 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

RE[7]: My thoughts on Go
by satsujinka on Wed 13th Feb 2013 19:30 in reply to "RE[6]: My thoughts on Go"
satsujinka Member since:
2010-03-11

Rename still isn't as flexible.

For example, in Go if you are using someone else's objects, you can still create interfaces that those objects implement, without needing to modify those objects (you don't even need their source code.)

Reply Parent Score: 2