The one thing that bothers me (which is not Caddy's fault at all) is the plugin system. If I understand correctly, I have to recompile Caddy for every plugin I want to use, right? Sounds like a limitation with Go which is really unfortunate.
Dynamic linking support was introduced in version 1.5, but it only works in GNU/Linux currently.
I expect it to eventually be available in all target OSes.
Caddy is very easy to use. You can download the build with what you want from their download page.
The nicest thing about it is very simple config file, TLS out of the box, automatically renew as well.
nope. That has been fixed with recent development versions that support loading plugins as shared libraries. For distros, that's very important because it allows them to ship much more configurable nginx packages as now plugins can be added as-needed.
Also, it makes distro packaging dreadful, since you can either ship nothing and be useless for nearly everyone, or ship everything and surprise users if they switch to the official builds and find out stuff is missing.
Nginx used to be as bad, but that's been fixed recently.
Personally Caddy is also not very useful for me, since I use a reverse proxy, and Caddy didn't seem very helpful there the last time I tried. Oh, and it would have been nice to be able to make it generate self-signed certificates for staging environments.
The article says 0.9 can now generate self-signed certificates like so
tls self_signedThe 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.
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.
That's exactly what I said, you're talking about dynamic linking not dynamic library loading.
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.
Yes it does, since version 1.5, but the toolchain doesn't support it yet across all supported targets.
Don't you have to link the executable explicitly with the shared libraries? I.e. no dlopen()-like plugins?
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.
go build -buildmode=c-shared- 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.
> 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.