I don’t think you’re a jerk, I just want to offer a different perspective.

I appreciate projects like this as a newbie. People say, “you can learn a lot by reading other people’s code.”

Unfortunately, most of the projects I try to learn from are quite large. It can be overwhelming to dissect. A project like this which sticks to the language (with few or additional libraries) allows me to pick apart what everything does.

And that's what these projects are great for. I have always appreciate simple things like this that allow me to learn new features of a language, or in this case the stdlib that comes with a language, without introducing too much cruft. I am still learning new tech and these kinds of demos are a great way to learn.

I am just being overly pedantic about the 100 LOC thing because it's been used over decades as a kind of badge of honor/bragging rights. If you implement something that really relies on nothing in N LOC then it's warranted. If it's just a teaching tool, like this is, I feel that it's better to present it as "Show HN: how I learned about HTTP support in the Ruby stdlib and wrote a toy proxy server". The README for this project actually makes it sound like this is something you could use in production, which you absolutely should not.

Yes, you are a jerk. Why? To quote / paraphrase nobel laurate Richard P. Feynman - you do not understand what you cannot build yourself. No better way to learn than to build your own proxy or you name it. See https://github.com/danistefanovic/build-your-own-x

Agreed. I am not at all against people learning how to do it. But if that's the purpose then it's probably better to present it as such (like the resources at your link does). But the claim that all you need is 100 LOC to make a proxy server work is a bit bogus when you rely on Ruby's standard library. Look at the code at https://github.com/jamesmoriarty/forward-proxy/blob/main/lib.... As expected, it doesn't parse headers but uses stdlib's code to do that. Good, less likely to have bugs. But that means that you can claim that you implemented an HTTP header parser in one line of code:

  req_headers = Hash[req.header.map { |k, v| [k, v.first] }]

It's good that you figured out how to do that, and it's useful. But that is not a 1 LOC HTTP header parser. It's an invocation of an opaque header parser that you do not understand. You might not even know what an HTTP header looks like and still write and use the above code.

Interestingly, above that code they write headers by hand. Those at least to me don't look right: they don't escape header values or handle multi-line headers. Probably should have used stdlib to write that part of the code.

I really don't mean to pick on this particular project. I just don't really get impressed with "X in Y LOC" when all it's doing is invoking the services of a standard library. I guess when you are coming from the NPM world where you need 1000 dependencies to concatenate two strings it seems really cool to only do something with the tools included. But better ecosystems allow you to do a lot more with the batteries included, which means your LOC will be really low until you do something more interesting.

I think the argument is that if you're depending heavily on a "batteries included" standard library of a high-level language, you in fact aren't really building it yourself.

Or at the very least that using the sort of badge of honor "in N LOC" isn't warranted.

Eh, who says it needs to be hard? As long as it solves a problem, it seems useful to me. And there may be people out there who aren't super familiar with Ruby or forward proxies who can learn a lot from this implementation.

Which isn't to say doing hard stuff is bad either. I've written simple servers in C as well, and those are fun projects that you can learn a lot doing. But I don't think that there's anything wrong with posting stuff like this.

I am not saying it has to be hard. Probably shouldn't have to be. I am saying that why is it noteworthy when it's just the exact glue code you'd expect? There is like 10k LOC that this is using underneath so the 100 LOC is very misleading here.

I suppose some people might be surprised that it can be done so easily in Ruby, or seeing that it's a short example gives a reason to check it out rather than if they'd assumed it was a much larger codebase they wouldn't have time to learn from. And all code is to some extent reliant on all sorts of hidden boilerplate - even a simple listen() call in C triggers a huge chain of function calls behind the scenes. And naturally higher level languages have higher levels of abstraction.

Agreed. Until you’ve programmed something with a magnetized needle and a steady hand, it’s not from scratch. I think somewhere between the “here is an HTTP proxy in 0 lines of code because I just used nginx/haproxy/varnish and wrote no code”, “here it is in 10 lines of code using Twisted/Tornado/Flask/whatever framework”, “in 100 lines using Ruby’s or Python’s stdlib”, and “I wrote it in C/Rust/Go using nothing but language primitives” the real work happens. Where that line is, is subjective because we are all at different places in what we know already and what we are currently learning. To my the only issue would be if people who know more try to misrepresent something to people who know less. As long as the goods are correctly labeled, it all has a place: we all need to know how to configure nginx, how to proxy a request using Twisted or Ruby’s standard library, and how to write a basic web server. I just think we should be careful not to mix them up.