undefined | Better HN

0 pointsvetinari9y ago0 comments

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.

0 comments

8 comments · 3 top-level

spriggan39y ago· 2 in thread

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

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

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

pjmlp9y ago· 2 in thread

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

vetinariOP9y 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?

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

icebraining9y ago· 1 in thread

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?

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

j / k navigate · click thread line to collapse

0 comments

8 comments · 3 top-level

spriggan39y ago· 2 in thread

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

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

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

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.

pjmlp9y ago· 2 in thread

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

vetinariOP9y 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?

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

icebraining9y ago· 1 in thread

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?

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

j / k navigate · click thread line to collapse