Hacker News Reader

Comment by mholt | Hacker News Reader

One of the advantages of Caddy is its purely static binaries. You don't even need libc to run Caddy, and that goes for any platform. The dynamic loading of plugins is at odds against this advantage.

> However, there's just no excuse for relying on recompilation instead of dynamically loading modules also written in Go and thus using the same runtime.

Actually there is.

Go plugins are something we're looking at, but it's complicated and the technology is currently immature. Please read this forum thread in full: https://forum.caddyserver.com/t/go-1-8-plugin-model/934?u=ma...

View on HN

Nice to see you on here, Mr Holt. Thank-you for the great work you've done with Caddy.

Like the rest of Caddy, I find the plug-in system to be simple and solid. Some people just seem to like complexity. (smile)

Is there any way to query what plug-ins are bound into a Caddy exe? (given that I'm a non-Go-programming, Windows guy)

An idea I had for the website was to allow us to sign in and have accounts. Downloads and plug-in preferences could be tracked. (It might even lead to a way to pry some money out of cheapskates like me with premium plug-ins and whatnot.)

Glad you like Caddy!

> Is there any way to query what plug-ins are bound into a Caddy exe?

Run `caddy -plugins`.

The new Caddy website -- coming out hopefully later this month -- will allow developers to create accounts and release their plugins themselves, without me having to do it manually. I have given some thought to allow anyone to create an account but I need to work out some details for monetization first, if that's the route it takes. Thank you!

Good to hear that Caddy might support real plugins, either optionally or by default. Please note that my criticism was not targeted at the Caddy developers. It's not your fault that the Go core developers have dragged their feet so long on making such basic functionality available, or that the Go community in general has enabled such dereliction. Writing Go code seems like it might be quite pleasant. Integrating Go code into the rest of that ecosystem is what gives me a huge "this isn't a safe way to do things" vibe.

Hmm... I don't think I've ever in my life worked on a platform where I couldn't get libc.

It sound like a neat project where there are some good defaults and where most weaknesses (performance, flexibility, etc) come from golang. It would be interesting to see a rewrite in another language.

Why is this seen as a benefit? If a severe security issue is found in libc, I have to recompile all software to take advantage of it? Who thought that was a good idea?

AFAIK, Go doesn't use libc.

Anyway, it is still a problem if you encounter a bug in any dependencie: you have to recompile every application using it.

Bare containers don't have libc, for instance.

Reply on news.ycombinator.com