That said, you mention PHP, I wonder how PHP running in HHVM compares to a more bare metal solution (or regular interpreted PHP).
https://awesomekling.github.io/pledge-and-unveil-in-Serenity...
That sounds like a lot of options. While I don't exactly like Go, that's very much the sort of things it was designed for, "stdlib-only" go will give you everything you need with pretty much guaranteed safety.
> Main fight must occur on the "C++ vs Rust" scene, but C++ certainly wont die in another 20 yers, so you happy using it for long-term projects.
The concern is less the death of C++ and more exposing C over the web, which exponentially increases the damage of any mistake you make (likewise C++ though likely with a lower exponent).
My build system is a makefile, and it feels like I'm parodying myself and the entire industry.
Is this the same?
I still use httpd as the proxy but use compiled Go executables for CGI.
> Yes. But some folks confused humour with levity.
Time to fire up the Wayback machine ;)
Last time I checked httpd didn't support http/2.
httpd's config syntax is mostly sane and error messages are mostly legible, and that it's written by OpenBSD's core devs inspires confidence. I recommend that system admins at least give it a try, especially if they've already decided to use OpenBSD. It can't do everything but I think it does enough to meet the needs of 80% of the web's sites.
Though, it comes with a somewhat steep learning curve.
But, in the end you can throw away that pesky search foo hat, and have some deserved peace of mind.
Some would argue that's a feature.
Has a nice ring to it. Maybe advertised as BACHS - a truly baroque stack
I think the best use case would be some static content delivery coupled with a few dynamic pages and APIs backed up by SQLite here and there ...
Some references would be cool I guess. Anyone?
But the real win with using C (or rather, using direct syscalls) comes from how much of that throughput you can retain while serving dynamic content. At least on Linux, performantly serving a static file would have a syscall flow similar to the following:
file -> splice -> pipe -> splice -> kTLS socket
The performance increase comes from copying the file to the socket without any detouring of the data via userspace. This can easily be adapted for the case where you need to inject portions of that file with dynamically retrieved content, by using offset fields in the splice call from the file being served, and manually writing to the pipe to inject the dynamic content. You cannot easily replicate this construct in any other dynamic-content server framework I know of - you have to do it manually in C (or any language that allows you to directly invoke system calls).
Seriously, how are you supposed to pronounce BCHS?
