If that were true (I'm not expert but I don't believe it to be the case), why would it be a problem? If it implements what people want efficiently enough and securely it shouldn't matter that it isn't written from scratch. Yes, anyone can tie libraries together, but if you are trying to work on something else you might not want to spend time doing that and resolving all the edge cases that you'll run into along the way.
> like Apache or Nginx would.
Apache started life as a huge collection of patches onto something else rather then implementing everything itself, and many would argue that this history still shows in negative ways at times.
Apache is a great project, but it really isn't a good example to use when trying to make the case for implementing everything in-project as efficiently as possible instead of using external dependencies.
> It's useful but certainly not "proved" in a production environment.
Some have already indicated otherwise on this thread.
Though as it hasn't been around all that long and has relativity recently seen significant internal changes so I'll grant that if you are being very careful you might not consider it mature/refined/proven enough for some production environments.
> if you are already using Go to develop servers, just use the libraries it uses directly.
IF you are already using Go. Many people aren't. I for one don't.
IF it were true (which I don't think it is) that it just strings libraries together
IF it didn't detract from your other ("not writing a http* proxy" based) project goals; because it took zero time & effort to put those libraries together and test & support the arrangement going forward, dealing with changes to said libraries over time, edge cases in their interactions, new and interesting problems in the wild due to odd client applications and proxies connecting to it, ...
I don't use Caddy yet (I have experimented with it and when time permits it will probably become part of my infrastructure at some point soon) so I have no particular axe to grind in support of it (other than it looks useful for my use case due to the relatively hassle free config and automatic LE certificate processing), but your argument against using it is at best flimsy.
Of course you may have registered a throwaway account in order to just troll a bit and get reactions; in which case good show sir, you appear to have achieved your goal!
That's not quite true. Maybe you are confused about the "module" aspect of Apache httpd and what it really means. Sure, there are a bunch of external, 3rd party modules, but the bulk of Apache capability is handled by bundled, official, "in-project" modules and not external dependencies.
No, I'm referring to Aapche originally starting life as a series of patches to the code for the NCSA HTTPd server and related libraries - stringing together existing code rather than being a fresh new implementation as implied by the comment replied to.
That is, this may not be someone using a throwaway account in lieu of their real account, but because they don't have a real account to use.