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 552205
To read all comments associated with this story, please click here.
Cross-compiling
by Laurence on Tue 12th Feb 2013 12:37 UTC
Laurence
Member since:
2007-03-26

I'd like to add something that's not already been commented on:

Go is a dream to cross compile with. eg I can write a program on x86 Windows, test it and then compile it for a Linux ARMv6, still on the Windows PC, and just copy the ELF over. No code modifications what-so-ever.

I know this can all be done in C++ and scripting languages as well. But Go makes the process significantly easier than C++ (in regards to the more complicated programs), with significantly less code than Java and compiles unlike scripting languages.

So while Go isn't perfect, it offers me the best balance between writing speedy code and having quick run times. Go is now my "minimum fuss" language.

Edited 2013-02-12 12:41 UTC

Reply Score: 5

RE: Cross-compiling
by moondevil on Tue 12th Feb 2013 12:47 in reply to "Cross-compiling"
moondevil Member since:
2005-07-08

Go is a dream to cross compile with. eg I can write a program on x86 Windows, test it and then compile it for a Linux ARMv6, still on the Windows PC, and just copy the ELF over. No code modifications what-so-ever.


This is only possible if you restrict yourself to the base library and Go pure code.

This is nothing new, cross-compiling exists since the dawn of computing.

Reply Parent Score: 3

RE[2]: Cross-compiling
by Laurence on Tue 12th Feb 2013 14:10 in reply to "RE: Cross-compiling"
Laurence Member since:
2007-03-26

I really wish people would read before arguing...

This is only possible if you restrict yourself to the base library and Go pure code.

Yet that's exactly what the context of this thread is about. We're not talking about some imaginary examples of Go which break convention; we're talking about Go code written as Go code is designed. And that means using non-OS specific API calls in the base to build extended non-OS specific Go libraries.

Go is designed with portability in mind. C++ wasn't. So while C++ can be portable, it's much easier to write portable code in Go.


This is nothing new, cross-compiling exists since the dawn of computing.

Thank you for telling me what I'd already categorically stated in my post.

My point was Go makes the process much less painful, not that it's the only language to have ever supported cross-compiling.



These days you can do pretty much anything in pretty any language. So the choice of language boils down to productivity (time spent coding, compiling, porting, etc) vs performance (raw execution speed, memory usage, etc) and sometimes even performance is a non-issue. So my point was this: Go enhances productivity. Which is why it's my new go-to language.

Edited 2013-02-12 14:20 UTC

Reply Parent Score: 5