> Has there been any memory safety issues with Nginx?

Yes, of course. For example, nginx uses openssl, so it was vulnerable to Heartbleed, something Caddy can never be vulnerable to. Part of the point of Caddy is to stop deploying C code to the edge.

> Nginx is easily extendable and has far, far larger plugin ecosystem than Caddy.

Nginx is also 4x older. I'd say for just a few years we're doing pretty good with our very young plugin ecosystem. A lot of this depends on the community. If you want it, make it so!

> So does nginx, with "nginx -s reload"

I think he was referring to a REST/JSON API that isn't unix-specific.

Good point about openssl!

> Nginx is also 4x older.

I know, but the GP claimed Caddy's plugin ecosystem was an advantage over Nginx, which just isn't true.

> I think he was referring to a REST/JSON API that isn't unix-specific.

Got it, thanks. Though I wonder how many people actually need a REST API for config reloads given practically everyone runs servers on Linux.

You'd be surprised how helpful having a REST API for config reloads is when you're serving more than a simple static site.

In addition to OpenSSL's Heartbleed, nginx had its own functionally-identical "Heartbleed" bug in its header parsing. Exact same impact.

(I don't think anyone made a big deal about it at the time; I knew about it because our team at Matasano discovered it independently just an hour or two before someone else filed the bug).

These 2:

- Built-in ACME client, automated certificate management

- Simpler configuration language, the Caddyfile

Are absolutely applicable and reasons that it's better. UX matters.

I'd argue it's much easier to write Go plugins for Caddy than C plugins for nginx, and it's much easier to build. See the plugin docs here: https://caddyserver.com/docs/extending-caddy

On the other hand, it's probably easier to write Lua for nginx?

More people write/know Go than Lua judging from the relative books, posts, job postings, conference sizes, and so on though...