4 ms·

It's a patchwork of different Go libraries, Caddy doesn't implement anything itself like Apache or Nginx would. It's useful but certainly not "proved" in a prod

It's a patchwork of different Go libraries, Caddy doesn't implement anything itself like Apache or Nginx would. It's useful but certainly not "proved" in a production environment. The heck you don't need Caddy if you are already using Go to develop servers, just use the libraries it uses directly.

0xmohit 10y ago
Do you really need a throwaway account to make a comment?
- kbenson 10y ago
  I think there's a certain subset of people that like to read HN but not submit/comment, either for reasons of anonymity or just because they don't want to. They may be inclined to comment from time to time, and create a temp account to do so, since HN does not allow anonymity. Also, it's possible they had an account that was banned/shadow banned, and refuse to make another full account out of protest. 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.
- pythia__ 10y ago
  It's funny how when they ask you if you really have to be anonymous it tips the scales towards "yes".
stemuk 10y ago
It is simply not true that caddy is JUST a collection of Go libraries, since parts of it like the Caddyfile concept are developed by Matt Holt, the (main) dev behind Caddy. Apart from that I would definetly say that Caddy is far easier to use than Apache or Nginx, which is a big bonus if you are just getting started in web development.
dspillett 10y ago
> It's a patchwork of different Go libraries, Caddy doesn't implement anything itself 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!
- jimjag 10y ago
  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. 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.
  - dspillett 10y ago
    > Maybe you are confused about the "module" aspect of Apache httpd and what it really means 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.

0xmohit 10y ago

Do you really need a throwaway account to make a comment?

kbenson 10y ago
I think there's a certain subset of people that like to read HN but not submit/comment, either for reasons of anonymity or just because they don't want to. They may be inclined to comment from time to time, and create a temp account to do so, since HN does not allow anonymity. Also, it's possible they had an account that was banned/shadow banned, and refuse to make another full account out of protest. 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.
pythia__ 10y ago
It's funny how when they ask you if you really have to be anonymous it tips the scales towards "yes".

stemuk 10y ago

It is simply not true that caddy is JUST a collection of Go libraries, since parts of it like the Caddyfile concept are developed by Matt Holt, the (main) dev behind Caddy. Apart from that I would definetly say that Caddy is far easier to use than Apache or Nginx, which is a big bonus if you are just getting started in web development.

dspillett 10y ago

> It's a patchwork of different Go libraries, Caddy doesn't implement anything itself 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!

jimjag 10y ago
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. 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.
- dspillett 10y ago
  > Maybe you are confused about the "module" aspect of Apache httpd and what it really means 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.