There are still lots of user space applications written in C/C++ nowadays, that could be easily rewriten in Go or any other safer language with native code compilers, without noticeble performance lost for the problem being solved.
The remainig issue for many of those is "need better GC". Apps like games could be brought in with near-pauseless GC that currently seems to exist only in Java land.
(Yes you can work around the current GC's but this drives away some developers)
Sometimes these applications are written in C for the extreme portability rather than performance. I have a couple open source projects in mind that support a huge selection of OSes and hardware configurations that would not be possible with some of the other current higher level language but almost every platform supports C to some degree. I don't know how well Go supports weird configurations like MMU-less uClinux installs but the GC wouldn't be what is breaking it.
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.
The main issue with that, is that although there are lots of GC enabled languages to choose from, not all of them have mainstream AOT compilers available.
Shipping a VM with the product is not always possible/desireable.
Even with that constraint, OCaml's 15 years old, so's SML/MLTon, D's 12 years old (D2 is 6 years old), Eiffel's nearly 30 (and moved under ECMA in 2005), Common Lisp can be compiled to native via CMUCL, SBCL or CCL and Scheme via Chicken Scheme or Chez Scheme.
And these are off the top of my head, I'm sure there are others.
