4 ms·

Go does not allow dynamic library loading. So either your plugin system have to be backed by a third party language that has a interpreter/vm/whatever coded in

Go does not allow dynamic library loading. So either your plugin system have to be backed by a third party language that has a interpreter/vm/whatever coded in Go, or you have to rely on some RPC method of some kind. So yeah it's a huge limitation with Go that makes it just unsuitable for a wide range of use cases.

vetinari 10y ago
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
Yes it does, but the toolchain support is not yet available for all operating systems. go build -buildmode=c-shared
- spriggan3 10y ago
  No it doesn't. How can you open dynamically a third party Go library from your Go binary ? you can't.
  - pjmlp 10y ago
    So what is that supposed to do?
    - spriggan3 10y ago
      What is a JAR loaded at runtime in Java code supposed to do ?
      - pjmlp 10y ago
        Well I expect it to work like this: - Define a Go interface for plugin - Create a C style shared library with a factory function - On the application side, load the library and cast the pointer to the plugin interface - Make sure the Go runtime is compiled as a shared library visible to the application and respective plugins It is as easy to put a jar into a directory? No, but it is doable.
        spriggan3 10y ago
        > Create a C style shared library with a factory function > On the application side, load the library Show me the code then, I still maintain than what you think is possible isn't. And I don't want to see any C code in your example.
        pjmlp 10y ago
        I might try to do it as a learning exercise of the state of Go tooling, but I have better things with my life than proving things to strangers on the Internet.

vetinari 10y ago

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

Yes it does, but the toolchain support is not yet available for all operating systems. go build -buildmode=c-shared

spriggan3 10y ago
No it doesn't. How can you open dynamically a third party Go library from your Go binary ? you can't.
- pjmlp 10y ago
  So what is that supposed to do?
  - spriggan3 10y ago
    What is a JAR loaded at runtime in Java code supposed to do ?
    - pjmlp 10y ago
      Well I expect it to work like this: - Define a Go interface for plugin - Create a C style shared library with a factory function - On the application side, load the library and cast the pointer to the plugin interface - Make sure the Go runtime is compiled as a shared library visible to the application and respective plugins It is as easy to put a jar into a directory? No, but it is doable.
      - spriggan3 10y ago
        > Create a C style shared library with a factory function > On the application side, load the library Show me the code then, I still maintain than what you think is possible isn't. And I don't want to see any C code in your example.
        pjmlp 10y ago
        I might try to do it as a learning exercise of the state of Go tooling, but I have better things with my life than proving things to strangers on the Internet.