61–70 of 71 posts
This is for both development on ARM systems (standard go commands, eg: go build, etc) and deploying to ARM systems (setting ARM as a compile target). That said, I'm genuinely curious why anyone would develop on an ARM-based system as opposed to your run of the mill desktop. I realize that standard towers may be supplanted by their SoC brethren, but so what? Will we all be using iMac-like computers as desktops in the…
This is one of Go's best features for me. You can trivially cross-compile statically linked binaries, copy them over to an ARM system and they run fine. Contrast that with C/C++ - sure you can cross-compile, and I have in the past, but it's a huge pain to set up and who ever remembers the command line options. Those "target triples" aren't even documented anywhere. Plus, good luck building a statically linked C++ pro…
What about LLVM? Go's support of cross compilation is laughable in comparison to the different LLVM backends. And you can just use the -arch armv7 and -arch arm64 shortcuts instead of those target triples. Also, FWIW, the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code from cgo's runtime so it can support the different architectures/platforms. Of cou…
I'm not sure what you mean by "cgo's runtime", but go runtime is in go since 1.5. Some bits are still written in assembly but that's mainly for performance.
I don't think targeting every arch (and virtual archs like asm.js you mention [though there is a 3rd party GopherJS]) and OS out there was ever their purpose.
In case you're interested, there is llgo which has recently been merged into LLVM. It's still not practical however.
> But I guess Google just hates Apple that much?
I don't understand what this is supposed to mean since LLVM does not belong to Apple, and Google is a heavy user and contributer thereof.
This is for both development on ARM systems (standard go commands, eg: go build, etc) and deploying to ARM systems (setting ARM as a compile target). That said, I'm genuinely curious why anyone would develop on an ARM-based system as opposed to your run of the mill desktop. I realize that standard towers may be supplanted by their SoC brethren, but so what? Will we all be using iMac-like computers as desktops in the…
http://techcrunch.com/2015/11/17/google-and-asus-launch-the-...
This is for both development on ARM systems (standard go commands, eg: go build, etc) and deploying to ARM systems (setting ARM as a compile target). That said, I'm genuinely curious why anyone would develop on an ARM-based system as opposed to your run of the mill desktop. I realize that standard towers may be supplanted by their SoC brethren, but so what? Will we all be using iMac-like computers as desktops in the…
Not everybody compiles all binaries they deploy on developer workstations. If you run ARM servers, it makes sense that your build servers are on ARM as well, especially since you should run tests on the same architecture you're deploying to.
Earlier quoted context omitted.
I run a Go program on a Raspberry Pi device, and it's actually very convenient to be able to quickly edit a Go file, and test with `go run` directly on the machine.
I also run go on RPi, and compiled either there or on a qemu layer because the support for cgo cross-compilation for ARM was lacking. This was back in 1.3; It may be better now.
Earlier quoted context omitted.
../../Sirupsen/logrus/text_formatter.go:28: undefined: IsTerminal The logrus library we use for logging doesn't support Solaris.
Looks like it does now: https://github.com/Sirupsen/logrus/blob/master/terminal_sola...
This is one of Go's best features for me. You can trivially cross-compile statically linked binaries, copy them over to an ARM system and they run fine. Contrast that with C/C++ - sure you can cross-compile, and I have in the past, but it's a huge pain to set up and who ever remembers the command line options. Those "target triples" aren't even documented anywhere. Plus, good luck building a statically linked C++ pro…
What about LLVM? Go's support of cross compilation is laughable in comparison to the different LLVM backends. And you can just use the -arch armv7 and -arch arm64 shortcuts instead of those target triples. Also, FWIW, the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code from cgo's runtime so it can support the different architectures/platforms. Of cou…
It does not have platform-specific C code, as there is no more C code anymore. It sure does have platform-specific Go code and platform-specific assembly code though.
> from cgo's runtime so it can support the different architectures/platforms.
There is platform-specific code in the runtime, and there is platform-specific code elsewhere in the standard library, e.g. in the syscall package, but it's not from "cgo's runtime" (whatever that means). Go does not require cgo to interact with the target system, even on platforms where the interaction is done through shared libraries, not system calls, like Solaris and Windows.
Earlier quoted context omitted.
What about LLVM? Go's support of cross compilation is laughable in comparison to the different LLVM backends. And you can just use the -arch armv7 and -arch arm64 shortcuts instead of those target triples. Also, FWIW, the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code from cgo's runtime so it can support the different architectures/platforms. Of cou…
> because it has platform specific C and assembly code from cgo's runtime I'm not sure what you mean by "cgo's runtime", but go runtime is in go since 1.5. Some bits are still written in assembly but that's mainly for performance. I don't think targeting every arch (and virtual archs like asm.js you mention [though there is a 3rd party GopherJS]) and OS out there was ever their purpose. In case you're interested, the…
Many bits in math and crypto have fast assembly variants, but the assembly code in the runtime and sync packages is not for performance, but because assembly is the only way to put data in the right registers, issue memory barriers, implement the right atomic operations and so on. Not performance.
Cool! What's the Go memory model look like? Is it stricter than ARM or could possibly working programs be broken when run there?
Btw, in case it's not clear, Go has worked on ARM for the last 6 years, this is not a new thing.
It is the job of the compiler and runtime writer to ensure this model on whatever target platform. It doesn't matter if the target platform has a strong or weak memory model. Correct Go programs written for the Go memory model should work correctly on any target.
Of course that it's possible to write Go programs that violate the memory model but work on amd64, and not on some other platforms. But those are incorrect Go programs (and the race detector has a very good chance of detecting these problems). I will note that it's significantly harder to write these programs accidentally in Go though, than it is to write them in C.
Earlier quoted context omitted.
Go already has 2 compiler implementations. There is gc (Go Compiler) and gccgo[0]. [0] https://golang.org/doc/install/gccgo
But LLVM already has a lot of good backends (emscripten, arm, ppc, x86, amd64). Why reinvent the wheel when you could just make Go a LLVM frontend and be done with it?
In the meantime, Go still supports more hardware ISAs than LLVM. Apparently reinventing the wheel is much cheaper than adding wheels to the old car.