More than a little unfair when the following is in the article:
I’m not going to write this completely from
scratch – I think parsing DNS packets is really
interesting, but it’s definitely more than 80
lines of code, and I find that it kind of
distracts from the algorithm.
Which, seems legit to me. This article was a fun read to refresh on exactly what goes on in resolving basic records.
I hereby do fully deny that there is anything the least bit clickbait-ish about this article, which is super interesting and all the more an achievement for its brevity. It demystifies what is the most annoying thing about trying to code the client side of DNS, and the fact that it uses the same DNS message parsing library every other Go programmer does isn't of the slightest import --- if the article hadn't used miekg/dns, some other lowbrow comment would be taking the author to task for reinventing the message codec wheel.
The world needs more simple recursive lookup examples, and absolutely does not need more explication of DNS message parsing, any more than than an article talking about etcd's Raft implementation would benefit from a hand-rolled implementation of Protobufs.
It's (sadly) telling that all the dismissals are focused on packet parsing, and not like, bailiwick checking, which is understandably missing, but also really important.
This is the key case I wish HN allowed editorializing the title. Regardless how good the article is (or isn't) when they have titles like this it's inevitable the conversation will be about how the title was overreaching. If people were encouraged to make titles like this into something like "Making a simple DNS resolver with miekg/dns in Go" or even just "A DNS resolver in Go" when posting we'd avoid this multiple times a day recurring problem.
Or maybe it already is encouraged and people just aren't aware this counts as "misleading" or "linkbait" since it's not well described what the cutoff point is.
Either way both titles like this one and discussions of have long gotten old.
Edit: looks like the article moved to "A toy DNS resolver", excellent choice of wording IMO.
"Making a simple DNS resolver with miekg/dns in Go" would have given me the false impression that the article was about how to use miekg/dns. "A DNS resolver in Go" would have given me the false impression that it was about a full-fledged DNS resolver meant for integrating with Go applications. The current title at least pushed me in the direction of understanding what the article is about, which is demonstrating how DNS resolution works using a short Go program.
That wouldn't be a false impression, this article is indeed about how to use miekg/dns to make a resolver. Your comments on the other title already apply to the current title as is, it's one of things people hate about these titles but at least the cut title avoids the line count/"nothing is from scratch" debates.
Increasingly more accurate titles always accepted of course though but one thing for sure is the class of "<x> in <y lines>" are demonstrably a continuous problem to the point they are talked about instead of the articles they represent, they are not just minor wording nits one could come up with after staring at a title long enough.
Edit: I really like the title the article itself changed to "A toy DNS resolver".
A small nit but it's actually important for the HN Rules of Titles: 'edit' and 'editorialize' are different things. You can sometimes edit a title, for instance if it's misleading or clickbait. You can't editorialize in titles no matter what.
The more general take I have seen is that it would give a "priority comment". That can result in problems like that but also more commonly just cause the comments to all act like a response to the "main" comment rather than general discourse on the topic. I can definitely see that though I also see the poster having a large amount of that control already in most cases since they get to pick the source they post.
