Validate Go concepts

[altu_faltu]

Wanted to validate some of the Go concepts

1. Build Go code
   Get someone else’s code . Make your code depend on someone else’s code. Create a build. This build would create a binary which is portable- I can build in my Mac but the build is going to run on Windows/Linux/any OS without modifying it.
   If compared to Java and NodeJs.
   The code import works like NodeJs and unlike Java
   The portable binary creation works like Java and unlike NodeJs

2. Usage of the Binary
   Since a binary is created in this language therefore comparing with Java.
   In Java - as a developer I can take someone else’s jar(the jar has to be build specifically for the purpose) and import the exposed methods/functions within my code. Someone else is secured as what he has written (the source code) is not visible to me, and I can work with whatever the other developer has exposed.
   With Go I cannot import the binary’s exposed methods/functions from my code. If my code is dependent on the following projects A B C D E . I have to explicitly depend on each of the projects’s source code. Each of their executables are useless if I want to encash their functionality them from my code.

3. Package Imports and Contracts
   Contracts-in the form of Class Types has been a big deal with developers. The idea is - as a developer I define what I can work with. Any other developer imports my code would be able to ‘see’ and ‘use’ only what I choose/let them see or use.
   As a Go developer I can define contracts but I cannot restrict other developers importing my code to only use the Contract which I have defined. The importing developer can import any other code which is made public within my package.

[NobbZ (Norbert Melzer)]

1. I’m not sure about your Java and JavaScript mentions in this paragraph, but a go executable is only runnable on the architecture/OS it was built for. A binary compiled for mac is not runnable on windows and vice versa. Please see GOOS and GOARCH documentation about how to cross compile.
2. Binaries are only created for executables. Libraries are compiled on the file as necessary and linked statically into your binary. The way how go works here, basically enables you to deploy closed source executables, but libraries have to be open source (to the target audience)
3. You can use the INTERNAL package, which at least makes its sub packages un-importable. Though as already mentioned, the code is visible to your target audience anyway, so they could just copy paste the implementation.

Binary only packages (which had enabled you to do closed source libraries) have been possible some time ago, but have been deprecated or removed with go 1.12 IIRC.