3 ms·

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 b

• 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.