102 points prophittcorey 1 hour ago 41 comments

paularmstrong 1 hour ago | parent

> Everything about marketyour.games is modern

I can't read any of the text on that page other than the headings. Is that what makes it modern? I assume the stack mentioned in the blog post is vibe-slop as well.

prophittcorey 42 minutes ago | parent

I wanted to try my hands at a monochromatic website and chose two shades that were far enough apart to pass a AAA contrast rating for accessibility. I'll try to improve it soon.

It was 100% human slopped :)

mrweasel 17 minutes ago | parent

My eyes aren't particularly bad, not at the point where I need glasses to read books, program or anything, but I'm at 160-170% zoom before it's comfortable to read. HN is the same... so it might just be me.

fmo91 1 hour ago | parent

It's not very clear to me why the author has chosen C in the first place. I appreciate the effort of sharing the experience with us, anyway.

EGreg 1 hour ago | parent

I'm old enough to remember when the OKCupid guys wrote their own webserver in C++!

I took the concept of "slots" in requests, from it: https://github.com/okws/okws

uecker 59 minutes ago | parent

Yesterday or so there was a post about using Zig. When I read it I thought that using C would work equally well.

christoff12 29 minutes ago | parent

Yeah, I thought it was interesting that both of these[0] were on the front page.

[0] - the other one: https://news.ycombinator.com/item?id=50051573

Kevin_Flynn 41 minutes ago | parent

I can never figure out why everything isn't in C. :|

prophittcorey 39 minutes ago | parent

I didn't want to state why C and not "X" because the comments would have devolved into an all out language war.

christoff12 31 minutes ago | parent

Fair enough. But I am also curious if you'd like to share your rationale.

afavour 1 hour ago | parent

A shame to hand code a project in C and then use AI to write a blog post.

It’s a cool project to test yourself but most of the benefits outlined would also apply to Go, Rust, etc, and then you also get memory safety thrown into the mix as well.

skrrtww 1 hour ago | parent

I don't think the post was written by AI.

It has headers like AI blogposts, and features a lot of parallel structure like AI blogposts ("there's no <blank>. you <blank>"), but if you actually read it none of it reads like slop. To me anyway.

xd1936 49 minutes ago | parent

Interestingly, Pangram says that exactly the first 50% is AI and the second half is not. ¯\_(ツ)_/¯

Muhammad523 37 minutes ago | parent

Not that those tools are that accurate

exe34 18 minutes ago | parent

It reads like autism to me. The theme confirms that.

EGreg 1 hour ago | parent

"Every request spawns a fresh process. Deploying a new version is replacing one file. That means no server restart and no downtime. New requests simply pick up the new binary."

I think that's why FastCGI exists. It is the equivalent of PHP's "Swoole" or "FrankenPHP" or "amphp" or Laravel's "octane", etc. Each process is long-lived and tries to clean up its state as much as possible between requests. Forking a new process can take around 8ms (https://news.ycombinator.com/item?id=19005586)

When I was building https://github.com/Qbix/webserver in PHP, I was faced with forking a new process per request. I implemented fork-per-request at first, similar to PHP-FPM and then implemented the "FastCGI" approach of long-lived processes that clean up after each request. (Modern PHP has introspection so the engine can know what to clean up, before calling the php files to handle things.) However, some things are not really possible to completely reset in PHP, and you have to be careful with database connection pools, etc. Typically those are left open even by preforking processes like php-fpm.

Anyway, I ended up flipping it: use the "FastCGI" approach as a default, and if the original PHP code doesn't work (rare), then for that app, you can choose the regular CGI approach of forking a process per request. That way you get maximum speed by default, and manually opt into safety (this is an exception to my usual priorities).

PHP is actually quite fast. But I was also interested in transpiling it to C. So I built the transpiler at: https://ulanguage.org/playground ... used Claude to transform about 1000 PHP functions to their native equivalents, but if you use any of the others, it would hook into the Zend runtime and link with it. (There are some nuances with zvals and objects, and resources in previous PHP versions, but I managed to overcome them.) By the way, it also works with Node and Python FFI the same way.

You can basically now take PHP, Python or Javascript/Typescript code, and speed up the CPU-bound parts about 10-50x. A lot of that is because of string and JSON handling. Many web apps use strings and JSON a lot. So underneath, I had the compiler use "ropes" for the strings, and avoid concatenation. It also parallelizes the JSON encode and decode into code that can run on multiple cores at once, i.e. large JSON payloads are encoded and decoded in parallel. Those are just huge speedups.

Anyway... all of this is mostly focused on speed optimization, so you can solve the literally C100K problem (forget C10K) today, on a regular box. If you don't need speed or FastCGI, your approach is fast enough for the vast majority of applications.

PS: By the way, if you fork after your program already loaded the framework and initialized the configuration, then you can run a lot more workers, literally 10x-100x more of them, because Linux and Mac will share all the loaded memory between processes, and do Copy-On-Write only on dirty pages. And when your request is done, and the process exits, that custom memory is efficiently cleaned up by the OS. It is this feature that allowed me to finally get the best of both worlds... run all existing PHP code, that makes blocking I/O requests all over the place to the database, filesystem, network etc. while at the same time being able to handle 100,000 requests in flight at the same time! Swoole and FrankenPHP can't do that.

iririririr 51 minutes ago | parent

what are the code paths in php you're dropping for the actual speed improvement? just the parsing?

if not, you could have sent patches and have the best of both worlds

Levitating 1 hour ago | parent

CGI is great. Sadly nginx doesn't support it natively as opposed to lighttpd.

I like this project for adding CGI to nginx: https://github.com/pjincz/nginx-cgi

There's also methods of starting Rack applications directly form nginx via passenger[1]. Rack is the CGI like interface for ruby webapps: https://github.com/rack/rack It easily allows for writing applications and middleware with a few lines of ruby.

[1]: https://www.phusionpassenger.com/documentation/Users%20guide...

BirAdam 1 hour ago | parent

fastcgi wrap.

marcelox86 1 hour ago | parent

Another interesting looking blog post that I can't bear to read without my eyes bleeding :(

smhenderson 12 minutes ago | parent

It supports reader view just fine...

Panzerschrek 1 hour ago | parent

> There's no separate database server. You open the database file through SQLite's C API.

> Every request spawns a fresh process.

How does it work when multiple concurrent requests are possible? Does SQLite allow simultaneous write access from multiple processes?

prophittcorey 57 minutes ago | parent

SQLite can handle multiple concurrent requests if it's set to WAL mode. Reading is all non-blocking/concurrent but writing is still synchronous. You should also set the "busy timeout" or else your blocked writes will timeout immediately.

warkdarrior 56 minutes ago | parent

Users who send concurrent requests will be summarily banned and their data deleted. It's the only way to be sure.

citrin_ru 54 minutes ago | parent

SQLite does allow write access from mulitple processes - file locks (fcntl) are used to ensure at any given moment only one of processes modifies the database (or WAL if WAL is enabled).

Scubabear68 1 hour ago | parent

From the article, "WRITING HTML AND CSS IN C ISN'T TOO BAD".

Um, any and all string handling in C is pretty miserable.

prophittcorey 59 minutes ago | parent

To be fair, the HTML and CSS in C wasn't too bad.. the Youtube scraper was also written in C and that was a lot more painful :)

sam1r 29 minutes ago | parent

I can empathize entirely. After writing a scraper for html in C, outputting html in C is a piece of cake.

Joker_vD 57 minutes ago | parent

If you do it with the string functions from the standard library then yes, it is.

prophittcorey 47 minutes ago | parent

The standard string functionality is painful. I wrote my own string view and string builder that work with fixed size strings. No memory allocations, etc.

PhilipRoman 44 minutes ago | parent

Emitting strings is fine, it's the parsing that sucks.

devmor 51 minutes ago | parent

I still like writing web applications in PHP for many of the same reasons listed here - modern PHP anyways.

I shy away from frameworks unless I am building something that I expect a large team to work on, or I specifically need multiple complex features that don't make sense to maintain.

I've written a few applications for my own personal use or targeted at friends/family recently that have no third party dependencies other than Bootstrap, which I still like more than tailwind for anything that doesn't need to look like a marketing page.

OleksandrC 50 minutes ago | parent

For people who find interest in weird web applications, I have been working on a game project, in C++, where the client is compiled to WebAssembly with Emscripten, and the application server is also implemented in C++ (behind nginx).

This is from pre-AI era also. The game is Civ-like. Custom engine from scratch (including both the 3D stuff, and all the web handling also).

Take a look: https://statebuilder.com/

codazoda 42 minutes ago | parent

It hasn't been touched in a long time, maybe that's because it's "complete", but here's a quick CGI library:

https://github.com/codazoda/cgi-lib

Quitschquat 32 minutes ago | parent

I worked on a FORTRAN 77 CGI application in the early 00s. I think the host was Apache httpd, on some old HPUX version.

ramses0 25 minutes ago | parent

My favorite trivia is that busybox has built-in cgi-bin support (and `rclone serve webdav` seems remiss to not mention as well). `https://elixir.bootlin.com/busybox/1.37.0/source/networking/...`

Everything the post mentions is 100% true and well-reasoned, especially with the inclusion of pledge/chroot/etc. for dropping privileges.

There's two diametrically opposed deployment mechanisms:

1) stack towers of glop on top of each other until you're running a simple `echo "hello world"` on top of a docker container inside a vm in a proxmox server as part of a k8s cluster under a hypervisor running on remote compute...

2) just run `bash -c 'echo "hello world"'` and front it with CGI (stateless, single binary, yada yada yada...)

Take a peek at https://github.com/Domain/bash.cgi ... not that i'm suggesting that 'bash over busybox using cgi-bin' is the "proper architecture", it's more trying to illustrate that the amount of code that holds you back from being nearly truly "frameworkless" is tiny and easy to reason about.

For some of the internal tooling I'm doing for work, I've been tending towards:

    some-cmd [--json|--markdown] ...yet-more-args...
When you use the process and shell environment itself as a repl, you start trending towards `[--cgi-bin]` would "just" be another output type, and the ability (nay: foresight!) to ensure that your commands are independent, reproducible, and only depend on their input arguments leads you directly towards being runnable in both "hostile" (ie: firecracker vm / lambda-style) or very "comfortable" environments (ie: shell, debuggers, unit/integration tests).

emersonrsantos 23 minutes ago | parent

Does anyone know if Hacker News uses CGI as well? I know there's some JavaScript and AJAX magic for the interactive elements on the frontend.

lilbigdoot 21 minutes ago | parent

I'm still in the middle of reading but I wanted to comment first that I had a pleasantly surprising experience a few years ago with CGI. I hadn't thought about CGI since I was a kid and I was tasked with adding a simple dynamic page to a server that had nothing running yet except apache. For whatever reason I though to try out CGI because of how simple the page was going to be, and yeah. Would recommend

I just got C FFI working in my LLVM based language last night so I'll need to take a look at playing around with BCHS :)