On Tuesday, 4 October 2022 at 05:47:49 UTC+1 squadglad...@gmail.com wrote: > We have some disk space restrictions and hence we do not want to include > the common code as a library in the service. That will increase the size of > each exe. We would like to keep the common code and service code > independent of each other. Changes in one should not affect or cause > recompilation of the other. >
See also this other recent thread: https://groups.google.com/g/golang-nuts/c/fYfFgIazqSA There are serious question marks around a Go main program calling a Go shared library or DLL, and you may end up debugging very difficult low-level issues. If the objective is just to save some disk space, then I'd suggest no. In fact, using the DLL may use *more* disk space overall, because of the size of the runtime it has to embed (even a "hello world" program takes nearly 2MB - tracked under #6853 <https://github.com/golang/go/issues/6853>), whereas compiling a library into your main binary will share the existing runtime. > We would like to keep the common code and service code independent of each other. Changes in one should not affect or cause recompilation of the other. That's a different requirement. You can achieve it using an interprocess communication mechanism like gRPC, and the Hashicorp go-plugin <https://github.com/hashicorp/go-plugin> library wraps that pattern for you in a secure and easy-to-consume way. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/26595478-7686-4e77-9749-1d7dc7ef07a1n%40googlegroups.com.
