For fun, does anyone have something like this in Rust? Curious about that language and this sort of thing would be fun to look at.
Isnt it in the book? https://doc.rust-lang.org/stable/book/ch20-01-single-threade...
Show HN: A little web server in C
51–60 of 121 posts
Re: Show HN: A little web server in C
#52This may sound sort of “old man waves at cloud” of me but one thing I’ve found sad is the gross over-complication of later versions of standards such that the sort of project linked here may not be as practical for something like HTTP/3 for example. Similarly, the large, muddled tool chain that is “required” to make modern JavaScript applications makes it hard for newer learners to really understand what is going on…
It can be simple, or it can be fast.
Or it can be neither. But it can't be both.
If you want fast web at all cost (and you need encryption), you get HTTP3/QUIC.
Re: Show HN: A little web server in C
#53Earlier quoted context omitted.
Peak HN right here folks. Pack it in we are done.
Impossible– no part of the thread has involved someone suggesting rewriting it in Rust, which means there's no opportunity for someone else to reply "This project seems like a perfect fit for golang, why would you suggest they use Rust instead?"
I could write this thread in an afternoon.
Re: Show HN: A little web server in C
#54Cool project, but this project demonstrates the reason I've stopped writing things in C. The standard library has garbage string functions and it seems every project has its own version of this file: https://github.com/robdelacruz/lkwebserver/blob/main/lkstrin... It's fun to write this (and read others' versions) the first 3 or 4 times, but it gets old quickly.
This is how I felt writing Go. Writing the same nongeneric functions with slightly different type signatures and/or endless interfaces and/or interface{} signatures. It's 2023.
You know Go has had generics for the last 15 months, right?
Re: Show HN: A little web server in C
#55Earlier quoted context omitted.
That's the "lazy, dumb" way of doing it --- write another string library. A much better way is to design your algorithms so they need a minimum of string manipulation, which is unfortunately on the more difficult side for text-based protocols like HTTP. Personally, I wish HTTP messages were closer to something like ASN.1 DER; there's little in the way of string manipulation necessary for those, and all the lengths ar…
or just parse in place: https://github.com/celcius-labs/tiny-http/blob/master/src/ht...
[deleted]
Re: Show HN: A little web server in C
#56Re: Show HN: A little web server in C
#57Earlier quoted context omitted.
never mind than MANY people dont need generics, and that generics have a significant compilation and runtime cost, in terms of time and memory. who cares right? and never mind that Go has had generics for over a year now right? sometimes having a small, stripped down language is better than having a huge bloated monster. I would point to examples, but you know what they are.
The Gopher narrative timeline as I remember it was: 1. Generics are bloated and don't allow us to have a single-pass compiler, which we need. 2. You don't need generics because go generate covers all the cases that generics cover (please ignore that this is a second pass). 3. Go has generics!
Yeah, for years C++ said they didn't need sealed/final classes. Then they finally added it. Similar "re-editing" of history was done.
When new C++ standard libraries are written, there is now active, public effort to review what exists in other languages. Finally.
Re: Show HN: A little web server in C
#58Earlier quoted context omitted.
never mind than MANY people dont need generics, and that generics have a significant compilation and runtime cost, in terms of time and memory. who cares right? and never mind that Go has had generics for over a year now right? sometimes having a small, stripped down language is better than having a huge bloated monster. I would point to examples, but you know what they are.
> never mind than MANY people dont need generics, and that generics have a significant compilation and runtime cost, in terms of time and memory. who cares right? I'm saying that I wanted them...? I didn't say need. I was able to operate without them. I simply _wanted_ them. Also maybe consider the way you're communicating? I didn't say Go was wrong. I said I didn't enjoy it. I'm allowed to not like things, and I'm a…
Very good points about need vs want. Every time I hear a response to a reasonable software request at work with, "Well, do you really need it?". I pat my left leg. It's a good leg; I like it; Very helpful, but, sadly not strictly necessary.
Re: Show HN: A little web server in C
#59Earlier quoted context omitted.
I understand what you’re saying, but if someone decides to post a link to their project that is an HTTP/3 server in under X lines of code but only implements HTTP/2 features, is it really an HTTP/3 web server?
the HTTP/3 standard for servers is not backward compatible with HTTP/2 servers, it is backward compatible with HTTP/2 clients . And vice versa And therefore, an HTTP/2 server calling itself compatible with HTTP/3 clients is OK
It might be OK on a technical level, but my concern is where someone is showing off a project they used to supposedly learn how to implement HTTP/3 but only goes far enough to use an HTTP/2 implementation because fully implementing 3 is too complex or not worth it.
Re: Show HN: A little web server in C
#60This may sound sort of “old man waves at cloud” of me but one thing I’ve found sad is the gross over-complication of later versions of standards such that the sort of project linked here may not be as practical for something like HTTP/3 for example. Similarly, the large, muddled tool chain that is “required” to make modern JavaScript applications makes it hard for newer learners to really understand what is going on…
It can be simple, or it can be fast. Or it can be neither. But it can't be both. If you want fast web at all cost (and you need encryption), you get HTTP3/QUIC.
At the end of the day, the question is never one debating simplicity. If you consider the amount of complexity implemented just to even boot into an operating system to run these systems, the lack of simplicity is already a forgone conclusion. The crux of issue is going back to abstractions and my worry is specific to how our abstractions are getting larger and larger and doing more work at even level with very tight coupling rather than creating systems that use more levels as needed.