4 ms·

There is also the Go approach, which is your code is platform independent, but you need to compile it for each platform. You get native code that is portable, b

There is also the Go approach, which is your code is platform independent, but you need to compile it for each platform. You get native code that is portable, best of both worlds. (Some might argue "Good C" can do this, but that is often quite hard and C doesn't have the kind of stdlib that Go has..)

beefsack 13y ago
I'd call that the static compiling approach, not just the Go approach. It's possible to statically compile in a wide range of languages.
- voidlogic 13y ago
  I was using Go as an example of this. The majority of statically compiled languages don't support compiling the same source code to a multitude of platforms. The same Go code and be compiled for x86, amd64, ARM and runs on Linux,OSX,Windows,FreeBSD,OpenBSD,NetBSD,Dragonfly,NaCL,Solaris and Plan 9. Not many statically compiled languages pull that off.
  - pjmlp 13y ago
    You can only pull that off in Go as long as you only use the runtime library, which is no different than other language. As soon as you bring a third party dependency, game over.
    - voidlogic 13y ago
      >>As soon as you bring a third party dependency, game over. There are tons of 3 party libraries written in pure platform portable Go that will cause you no issues. In fact the vast majority of 3rd party Go libraries are just as portable as the stdlib.
      - pjmlp 13y ago
        So they provide implementations on all targets supported by Go compilers for the features required outside stdlib?
        voidlogic 13y ago
        The point is they don't have to- while Go compiled binaries are platform specific, pure Go code is platform independent. That means any platform that runs "go build" can run your Go program.
        pjmlp 13y ago
        You are avoiding to answer the question. There isn't pure Go code if it requires to touch the file system, talk to OS using APIs not available in the stdlib. The moment you depend on libraries outside stdlib, you are opening yourself to dependencies to cgo and/or OS syscalls outside your control. Even some stdlib packages are UNIX specific, e.g. os.user and log.syslog.
        voidlogic 13y ago
        >You are avoiding to answer the question. I'm really not, I am missing your point. The majority of 3rd party Go code simply uses the Go stdlib just like our hypothetical program. Go is no less platform independent then Java, for example, yes there are some 3rd party Java libraries that use JNI, just like some Go libraries use cgo. The fact that these native bindings to (often) platform dependent code exist does not make pure Go/Java programs non-platform independent. Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm thinking of the Go repos people put on github or the Gorilla project (http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/), I am not talking about using cgo to call glibc or something similar.
        pjmlp 13y ago
        > Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm thinking of the Go repos people put on github or the Gorilla project (http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/), I am not talking about using cgo to call glibc or something similar. The thing is, there aren't first and second class 3rd party libraries, all are 3rd party.
pjmlp 13y ago
Back in the day all languages allowed this. Go design leaves a lot to be desired, but at least it is a way to show the younger generations that didn't learned the above listed languages, how memory safe languages can be compiled to native code without a VM in the middle.

beefsack 13y ago

I'd call that the static compiling approach, not just the Go approach. It's possible to statically compile in a wide range of languages.

voidlogic 13y ago
I was using Go as an example of this. The majority of statically compiled languages don't support compiling the same source code to a multitude of platforms. The same Go code and be compiled for x86, amd64, ARM and runs on Linux,OSX,Windows,FreeBSD,OpenBSD,NetBSD,Dragonfly,NaCL,Solaris and Plan 9. Not many statically compiled languages pull that off.
- pjmlp 13y ago
  You can only pull that off in Go as long as you only use the runtime library, which is no different than other language. As soon as you bring a third party dependency, game over.
  - voidlogic 13y ago
    >>As soon as you bring a third party dependency, game over. There are tons of 3 party libraries written in pure platform portable Go that will cause you no issues. In fact the vast majority of 3rd party Go libraries are just as portable as the stdlib.
    - pjmlp 13y ago
      So they provide implementations on all targets supported by Go compilers for the features required outside stdlib?
      - voidlogic 13y ago
        The point is they don't have to- while Go compiled binaries are platform specific, pure Go code is platform independent. That means any platform that runs "go build" can run your Go program.
        pjmlp 13y ago
        You are avoiding to answer the question. There isn't pure Go code if it requires to touch the file system, talk to OS using APIs not available in the stdlib. The moment you depend on libraries outside stdlib, you are opening yourself to dependencies to cgo and/or OS syscalls outside your control. Even some stdlib packages are UNIX specific, e.g. os.user and log.syslog.
        voidlogic 13y ago
        >You are avoiding to answer the question. I'm really not, I am missing your point. The majority of 3rd party Go code simply uses the Go stdlib just like our hypothetical program. Go is no less platform independent then Java, for example, yes there are some 3rd party Java libraries that use JNI, just like some Go libraries use cgo. The fact that these native bindings to (often) platform dependent code exist does not make pure Go/Java programs non-platform independent. Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm thinking of the Go repos people put on github or the Gorilla project (http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/), I am not talking about using cgo to call glibc or something similar.
        pjmlp 13y ago
        > Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm thinking of the Go repos people put on github or the Gorilla project (http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/), I am not talking about using cgo to call glibc or something similar. The thing is, there aren't first and second class 3rd party libraries, all are 3rd party.

pjmlp 13y ago

Back in the day all languages allowed this. Go design leaves a lot to be desired, but at least it is a way to show the younger generations that didn't learned the above listed languages, how memory safe languages can be compiled to native code without a VM in the middle.