4 ms·
I would seriously recommend against building your own network stack for production use. Or writing your own web server for production use. Or database (whatever
by Ekaros 1mo ago
I would seriously recommend against building your own network stack for production use. Or writing your own web server for production use. Or database (whatever SQL or NoSQL) also for production use.
These sort of things are more complicated than you could expect and have plentiful pitfalls. Whatever you can do in reasonable amount of time is probably not that good compared to existing alternatives.
If you have actually pressing reason to build one and are ready and have means to spend time and effort on it go ahead. But carefully consider the effort needed...
- EGreg 1mo ago[flagged]
- znnajdla 1mo agoholy shit. I was just tinkering with my production Laravel stack serving thousands in production trying to figure out how to improve worker concurrency (running out of RAM) and I encounter a random comment on HN which appears to solve my exact problem. This is so serendipitous
- matltc 1mo agoWhat is up with the README?
- EGreg 1mo agoMeaning?
- pbkompasz 1mo ago3446 lines
- globular-toast 1mo ago> I worked closely with Claude though
- EGreg 1mo agoI did! Yes
- inigyou 1mo agoClaude wrote you a web server
- drfloyd51 1mo agoAI tooling will eventually become the default. Engineers are an implementation detail.
- hyperbolablabla 1mo agoWanting to incorporate an http server into a C project of mine, the only battle-tested or feature-complete options either allocated dynamic memory UTH without an option to override the allocators, or are too opinionated with the core API, like mandating callbacks for everything. Suprisingly there's no decent (single header) C library that don't have these 2 issues, at least that I could find.