4 ms·

Go does allow for consuming dynamically linked libraries, but it's not that simple as with C. For example, you have probably seen OpenGL bindings for Go - that'

Go does allow for consuming dynamically linked libraries, but it's not that simple as with C. For example, you have probably seen OpenGL bindings for Go - that's one of these things that would not work without dynamic linking. The issue is, that Go runtime has it's own ideas how the memory layout and stack layout should look like and these ideas are not compatible with __stdcall or __cdecl, so when calling C code, the runtime has to do a clean up. That used to involve a thread switch, now it involves a full register swap. What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps.

pjmlp 10y ago
> What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps. Yes it does, since version 1.5, but the toolchain doesn't support it yet across all supported targets.
- vetinari 10y ago
  Do you mean -buildmode=shared and -linkshared for linux/amd64? Don't you have to link the executable explicitly with the shared libraries? I.e. no dlopen()-like plugins?
  - pjmlp 10y ago
    Yeah something like that. Not sure how it exactly works, I just happen to still follow Go every once in a while. I see it as a good C replacement for many use cases that don't really need C as portable Assembler features. So from the gonuts discussions and design documents, I assume that at least on GNU/Linux systems it is already possible.
icebraining 10y ago
What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps. Since Go allows you to call C libraries, and allows you to write C libraries, couldn't you write a Go program that loaded a Go library but just talked over a C-style API?
- spriggan3 10y ago
  > Since Go allows you to call C libraries, and allows you to write C libraries, couldn't you write a Go program that loaded a Go library but just talked over a C-style API? It would be like writing a Go interpreter in C. Pointless.
spriggan3 10y ago
> What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps. That's exactly what I said, you're talking about dynamic linking not dynamic library loading.
- vetinari 10y ago
  It allows dynamic loading, but only C code, not Go code. You can do dlopen()/LoadLibrary() and then dlsym()/GetProcAddress(), but only with C calling convention.
  - spriggan3 10y ago
    > It allows dynamic loading, but only C code, not Go code. You can do dlopen()/LoadLibrary() and then dlsym()/GetProcAddress(), but only with C calling convention. That's a C feature not a Go one. You still can't do that ie calling a Go compiled library from a Go executable AT run time, like one can load JAR and execute some Java code from a Java program at runtime. Because the language doesn't allow that. No matter how you people try to spin that thing this is impossible to do with Go directly. Period. Using C involves a crazy overhead and complexity which is absolutely not worth it.

pjmlp 10y ago

> What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps. Yes it does, since version 1.5, but the toolchain doesn't support it yet across all supported targets.

vetinari 10y ago
Do you mean -buildmode=shared and -linkshared for linux/amd64? Don't you have to link the executable explicitly with the shared libraries? I.e. no dlopen()-like plugins?
- pjmlp 10y ago
  Yeah something like that. Not sure how it exactly works, I just happen to still follow Go every once in a while. I see it as a good C replacement for many use cases that don't really need C as portable Assembler features. So from the gonuts discussions and design documents, I assume that at least on GNU/Linux systems it is already possible.

icebraining 10y ago

What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps. Since Go allows you to call C libraries, and allows you to write C libraries, couldn't you write a Go program that loaded a Go library but just talked over a C-style API?

spriggan3 10y ago
> Since Go allows you to call C libraries, and allows you to write C libraries, couldn't you write a Go program that loaded a Go library but just talked over a C-style API? It would be like writing a Go interpreter in C. Pointless.

spriggan3 10y ago

> What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps. That's exactly what I said, you're talking about dynamic linking not dynamic library loading.

vetinari 10y ago
It allows dynamic loading, but only C code, not Go code. You can do dlopen()/LoadLibrary() and then dlsym()/GetProcAddress(), but only with C calling convention.
- spriggan3 10y ago
  > It allows dynamic loading, but only C code, not Go code. You can do dlopen()/LoadLibrary() and then dlsym()/GetProcAddress(), but only with C calling convention. That's a C feature not a Go one. You still can't do that ie calling a Go compiled library from a Go executable AT run time, like one can load JAR and execute some Java code from a Java program at runtime. Because the language doesn't allow that. No matter how you people try to spin that thing this is impossible to do with Go directly. Period. Using C involves a crazy overhead and complexity which is absolutely not worth it.