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

31–40 of 121 posts

Re: Show HN: A little web server in C

#31

Post by sharikone »

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…

Some elegant abstractions are created too. JS modules, for example. Or, in another field, the Language Server Protocol.

But yes, humans are humans and everything that is "simple" will get built upon and then become the backbone of something complex that will engulf and smother it as it evolves.

Re: Show HN: A little web server in C

#33

Post by zokier »

adamrezich wrote: post #23

this is a great opportunity to ask something I've been wondering about for awhile: what are the best options out there for hosting websites built as HTTP-serving executables (either Windows or Linux)? is it possible to do this relatively cheaply? I ask because I've been working on a framework[0] for building websites in a compiled language recently, and while it's been a ton of fun to build and test locally as a hobb…

For AWS simplest thing is to throw it into docker container (`FROM scratch` can work) and run in Fargate (AWS' container runtime). But its not super-cheap solution; baseline cost is something like $20/mo for Fargate and additional $20/mo for load-balancer. Lambda can work too, but it is in some ways bit more involved.

Cheapest AWS solution would be just EC2 instances (=basic virtual machines). t3a.nano instances cost just $3.5/mo and do not require additional load-balancers.

The modern cloudy approach would be to look into stuff like CloudFlare Workers, iirc they can run WASM, so if you manage to compile your code to that then it might work.

Re: Show HN: A little web server in C

#34

Post by userbinator »

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 are prefixes instead of "try to find the terminator" (and don't forget to not run past the end of the buffer...)

Re: Show HN: A little web server in C

#35

Post by alex_lav »

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.

> 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 allowed to post about them.

_Also_ this concept of "need" is amusing to me. You don't _need_ a garbage collector, or a statically linked binary, or static typing, or IDE support, or a debugger, or, or ,or.

And yet, people _want_ them.

> and never mind that Go has had generics for over a year now right?

Their generics implementation is pretty bad IME. Interfaces lacking type parameters seems pretty untenable to me. I'd rather just not use them.

> sometimes having a small, stripped down language

Of all the things Go is, I wouldn't say its either of these.

But also, if you respond, please try to not be so defensive. You can like Go, that is a valid thing to do.

Re: Show HN: A little web server in C

#36

Post by krapp »

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.

>It's fun to write this (and read others' versions) the first 3 or 4 times, but it gets old quickly.

I mean, you can always just use an existing string library or reuse your own. There's no reason to rewrite string operations for every project.

Re: Show HN: A little web server in C

#37

Post by denotational »

dajtxx wrote: post #17
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.

I know it's not your code, but related to this comment, it looks like it missing a check for lks == null? https://github.com/robdelacruz/lkwebserver/blob/main/lkstrin...

That assert is checking a library invariant; it should never fail unless there’s a bug in the string library itself (although I’m not entirely sure this string library would tolerate a malloc failure from a quick glance through).

This is distinct from checking the parameters; if lks is null then the user of the API has made an error. Some libraries may sanitise user parameters, others don’t. At any rate, an assert would be the wrong choice to check user parameters since this would result in a (recoverable) user error leading to an abort unless the assert is disabled at compile time (-DNDEBUG), returning an error would be a better choice.

Re: Show HN: A little web server in C

#38

Post by svnpenn »

vore wrote: post #30
2h wrote: post #25

Earlier quoted context omitted.

> you end up boxing your values to place into collections rather than letting the compiler monomorphize it. you know that Go has interfaces right? and I dont just mean the "any" interface. you can write your own interface similar to io.Reader and others, then add types that implement that interface, then no type matching is needed. > non-generic legacy cruft AKA normal, fine code. generic code is not some magic pixie…

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 project, and end user negative impacts in regards to time and memory. but advocates often dont know or care about these drawback, and only howl that GENERICS ARE MISSING until they are added, consequences be damned.

I'm just saying that while generics are useful in some cases, they are not always the right answer, and it shouldn't just be assumed that every language needs them, nor that any non-generic language "sucks".

Re: Show HN: A little web server in C

#39

Post by alex_lav »

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…

> I'm just saying that while generics are useful in some cases, they are not always the right answer, and it shouldn't just be assumed that every language needs them, nor that any non-generic language "sucks".

It's funny to me, because this comment chain exists because I said I got tired of rewriting the same functions with minute changes, the exact problem generics is intended to solve. I didn't say anything sucked, or even that I didn't like Go, just that this one aspect got tiring.

And yet, this small comment lead into a person feeling their language was being attacked.

Re: Show HN: A little web server in C

#40

Post by wahern »

GuB-42 wrote: post #24
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…

The big thing that makes HTTP/2, HTTP/3 and even Gemini hard to implement is TLS. I theory, HTTP/2 don't require it, but in practice, it does. You need to implement a variety of ciphers, manage certificates with expiration dates, etc... And if you wanted to implement all that yourself, people will yell at you for doing your own crypto. So yeah, you need a library. But not just that. You need a way to update your cert…

Generally speaking, you also need some sort of an operating system to make use of HTTP, and yet that doesn't figure into the complexity of HTTP.

In classic HTTP TLS was layered beneath it, providing important degrees of freedom, including the freedom to not use TLS, which can be especially important for experimentation and development.

Prediction: If HTTP/3 manages to substantially replace classic HTTP+TLS, QUIC is destined to become a kernel-provided service like TCP, shunting all that complexity behind an OS abstraction and freeing user space. The fact QUIC uses UDP is an important aspect here because a performant userspace QUIC stack conflicts with classic, high-value abstractions like file descriptors and processes; abstractions which make it viable (i.e. cheap) to have a rich, diverse ecosystem of languages and execution environments in userspace. More importantly, HTTP will have come full circle.

Post reply on HN