Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A little web server in C

github.com

Post reply on HN
Print view View original

41–50 of 121 posts

Re: Show HN: A little web server in C

#41

Post by jeremyjh »

userbinator wrote: post #34
skulk wrote: post #10

Cool 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.

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…

Peak HN right here folks. Pack it in we are done.

Re: Show HN: A little web server in C

#42

Post by [deleted] »

samtho wrote: post #11

This 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…

[deleted]

Re: Show HN: A little web server in C

#44

Post by kerkeslager »

2h wrote: post #20
alex_lav wrote: post #16

Earlier quoted context omitted.

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.

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!

Re: Show HN: A little web server in C

#45

Post by favorited »

jeremyjh wrote: post #41
userbinator wrote: post #34

Earlier 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…

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?"

Re: Show HN: A little web server in C

#46

Post by mst »

alex_lav wrote: post #35
2h wrote: post #20

Earlier 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…

It's still on my "I keep meaning to play with this" list because I keep getting distracted by other shiny things but you might find gomacro interesting.

Re: Show HN: A little web server in C

#47

Post by brickteacup »

svnpenn wrote: post #38
vore wrote: post #30

Earlier quoted context omitted.

If you are using interfaces, the value is necessarily boxed as the storage for the value may be heterogeneous. Once a value is typed as e.g. `io.Reader`, dispatching to its methods necessarily requires a vtable lookup (i.e. runtime cost!). Compare this to parametric polymorphism where you can avoid the type erasure and perform static dispatch at compile time. Though, unfortunately, Go's implementation of generics ("G…

> I make no claims about use of generics making your code being absolutely good or bad, but I do make claims that use of generics can make your code less error-prone and safe. Right. this is the issue right here. people only see that Go didn't have generics, and they never stop for a second to think WHY Go didn't have them. Generics have an implementation cost for the Go project, and maintenance cost for the Go proje…

> stop for a second to think WHY Go didn't have them

I have thought about this. I concluded that Go doesn't have generics because it's a poorly designed language whose designers elected to ignore decades of progress in programming language design for... reasons. Hence why you have to do the moral equivalent of passing around void pointers and checking return codes in $current_year

Re: Show HN: A little web server in C

#48

Post by jerrysievert »

userbinator wrote: post #34
skulk wrote: post #10

Cool 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.

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...

Re: Show HN: A little web server in C

#49

Post by kragen »

samtho wrote: post #11

This 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…

i'm concerned about this too

google isn't really concerned about creating elegant abstractions so much as they are about improving the performance of their browser talking to their server, though sometimes these do coincide

Re: Show HN: A little web server in C

#50

Post by kragen »

if you like this, you might like httpdito

http://canonical.org/~kragen/sw/dev3/httpdito-readme

http://canonical.org/~kragen/sw/dev3/server.s

it's a 2-kilobyte executable written in i386 assembly that can handle 20000 requests per second on my laptop, but only serves up files from the filesystem; no cgi or reverse proxy

instead of being single-threaded or preforking it just forks a child per request

Post reply on HN