Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't really understand concepts of low level languages, but I've had a perception that if I'd wrote a program in Go using the standard libary and compiled it with go build it would run on all imaginable platforms. Now, as far as I've understood your comment suggests that I'm wrong.

Lets suppose that some corporation would download the binaries of my project and use it on an embedded system, would it run?



It depends on how "embedded" embedded means to you. I've talked to some people who call a CPE Linux/Atom box embedded and I know some people who don't consider anything with an OS embedded. I won't even touch that argument. :)

But I used MMU-less uClinux as an example because it breaks a lot of assumptions that are made in a lot of code. No dynamic linking(which if I remember go doesn't support by default, or does it even support at all? I haven't written any in a year or two), no protected memory, and no real fork (vfork instead) crosses a lot of code off the list on what you can run. I don't know if go can support it, but I know that the current offical toolchains don't. There may be a feature go has that prevents them running on a platform like this, but it won't be GC. There are some GC'd languages that will run on this platform.

C is great in that is makes very few assumptions and if written carefully can be extremely portable. The base language doesn't even assume there is an OS present. I've only run into one platform that had very little C support. It was a small 8 bit uC that had a very strange execution stack that made C as everyone uses it hard to efficiently implement.


In addition to what stusmall's said about "it depends what you mean by embedded":

Go compiles to native code, not bytecode. Your post makes it seem like you might be missing this fact.

Go has good cross-compile support so from say a Windows box I can compile a Go program using just the standard library that will run on Windows, or I can compile one that runs on MacOS, or I can compile one that runs on Linux, and I can even compile one that runs on a different processor arch (like I can be running Windows/x86 and compile a binary for Linux/ARM, for example).

But(!) you have to compile a separate binary for each of those platforms, you can't compile just one single executable that runs on all of those systems. The output of the Go compiler is native machine language code for a specific architecture and OS.

eg. I want to compile an http server and run it on either a Windows/x64 box or a chumby Linux device and I'm currently on a Linux/x86 system:

cd mygoprogram

export GOARCH=arm

export GOARM=5

export GOOS=linux

go build

I now have an executable in the current working directory named "mygoprogram" that will run on a Linux system with an ARMv5 processor (say, an old chumby device)

export GOARCH=amd64

export GOOS=windows

go build

I now have an executable in the current working directory named mygoprogram.exe that will run on a Windows/x64 system, but it is completely separate from the binary that will run on the Linux/ARM device despite being built from the same source code.

mygoprogram.exe will not run on the Linux system, and vice versa. Go is like C/C++ in this regard as opposed to say Java where a common bytecode format will make the compiled code still platform independent.


Depends on the implementation.

Don't mix languages with implementations.

Currently there are two native compiler toolchains for Go, which only support a given set of OSs and computer architectures.

Additionally some people written Go interpreters with another set of supported targets.

So to answer your question, it would run on the embedded system if :

1 - the hardware could cope with Go runtime requirements

2 - it would be a supported target for one available native code toolchain




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: