3 ms·

I am a huge fan of simplicity when it comes to software development (although I must admit I'm not always great at achieving it), but I wonder whether the BCHS

I am a huge fan of simplicity when it comes to software development (although I must admit I'm not always great at achieving it), but I wonder whether the BCHS stack really offers anything that couldn't be achieved with a more "modern" stack. httpd would be one of the things I'd look at, it's absolutely great software, but I wonder whether it really achieves the most simplicity from a developer point of view. For instance, in simpler deployments I would generally reach for Caddy [0], which does things such as certificate renewal automatically for me. However, the part of the stack that really irks me is C. I'm a huge fan of C in an ideal world (where developers are perfect), and I respect the language for its role in the history of software development, and in the context of UNIX, however I just don't understand why use it in 2023 for something such as a web service. A web service is going to handle untrusted user input, deal with network boundaries, and is security-critical. A memory-unsafe language, where undefined behavior is easy to create but hard to find, which doesn't provide a lot of (useful) abstraction primitives other languages would provide, seems like the wrong choice. That's even before we start talking about how cumbersome it is to handle "strings" in C. I'd wager Golang or Rust are always going to be better alternatives to C when it comes to developing web services. Golang makes deployment specially easy, while Rust provides similar or better performance than C, but provides more safety (memory and UB) and better abstraction primitives. I believe I understand the purpose of this stack, and roughly who is going to enjoy it, just wondering whether I'm overlooking something, as I must admit I have never actually built a production service using CGI/C/httpd. I see this stack as something that's more philosophical rather than pragmatic towards development, if that makes sense, which is something I respect but wouldn't use (other than if I'm doing it just for fun). [0]: https://caddyserver.com/ https://caddyserver.com/

bawolff 3y ago
> I must admit I have never actually built a production service using CGI/C/httpd Nor would you probably want to. In addition to the security nightmere that hooking an inexperienced c programmer's c program directly to the internet is, CGI is not really known for scaling all that well. Like if you were really doing this on a real high performance site you'd probably want to use FastCGI. But also you just wouldn't do this. If you want to be low level, at least use rust.
- bsdpufferfish 3y ago
  The cost if launching a process that’s not a JIT interpreter is tiny. It’s also a fixed cost, so it does scale. In 2023 people are using lambdas on was. Slow cgi is fast enough.

bawolff 3y ago

> I must admit I have never actually built a production service using CGI/C/httpd Nor would you probably want to. In addition to the security nightmere that hooking an inexperienced c programmer's c program directly to the internet is, CGI is not really known for scaling all that well. Like if you were really doing this on a real high performance site you'd probably want to use FastCGI. But also you just wouldn't do this. If you want to be low level, at least use rust.

bsdpufferfish 3y ago
The cost if launching a process that’s not a JIT interpreter is tiny. It’s also a fixed cost, so it does scale. In 2023 people are using lambdas on was. Slow cgi is fast enough.