I, for the most part, agree with Drew in the three cited articles. 
You've also previously rebutted one of my own articles, and at the time 
I read a few of your other rebuttals. Revisiting it now, I've noticed 
and overarching theme for all your rebuttals: Perfect is the enemy of 
good.

That is, when you perceive a system or tool as flawed or imperfect, it 
is inappropriate for anyone to praise or prefer those systems. Since C 
and POSIX aren't perfect — and they certainly aren't — it's wrong to 
advocate for their use. Sometimes being imperfect simply means they 
don't make the particular trade-offs you personally prefer.

For instance, one of your criticisms of UTF-8 is that it doesn't support 
random access. This is absolutely true, but accessing Unicode code

It *should* be binding to all available interfaces. In the source you 
can see it uses INADDR_ANY or in6addr_any. This is currently not 
configurable, meaning you haven't accidentally changed it. Testing now 
on both Debian and FreeBSD, I can connect to Endlessh via localhost 
using telnet just as you showed. Perhaps you have a local system 
configuration that's causing an issue?

Your requirement to have the service available on localhost makes sense, 
and I'd expect Endlessh to support it.

This is very interesting, thanks! I didn't think these 32-bit integer 
operations were practically on the table for WebGL, but this proves 
otherwise. I'm glad to see that it actually works. I've updated my 
article with links to these Shadertoy experiments.

Oh, duh, you're right! It seems so obvious now that you've spelled it 
out. I've added an update to my article about this. Thanks!

I did some reading of the RFC to catch up.

The change with .strip() doesn't account for the fact that Message-ID 
isn't a required field. If not present, this method will be called on 
None. It was already expected this might be None ("not msgid"), so this 
also isn't consistent with the existing code.

The In-Reply-To header may contain multiple Message IDs, and this 
possibility isn't considered. However, not a single email in my personal 
archives has more than one Message ID in In-Reply-To. Mutt supports 
crafting such messages, and I was able to do so in a test. Since it's so 
unusual and rare, and would be really confusing for threading (what 
happens if a message spans independent threads?), it's probably not 
worth considering.

I'm seeing quite a lot of oddball email today! Here's a similar 
situation:

https://lists.sr.ht/~skeeto/public-inbox/%3C87pnfb69f3.fsf%40bernat.ch%3E
https://lists.sr.ht/~skeeto/public-inbox/%3C87a76f4fro.fsf%40bernat.ch%3E

The Message-ID and In-Reply-To match up, but they're not threaded 
together. Looking closely at the headers, Vincent's In-Reply-To includes 
a parenthetical. In my personal email archives that only occurs 0.49% of 
the time (i.e. 49 messages in every 10,000), so it's pretty rare. 
Perhaps lists is treating this as part of the ID? (Maybe the RFC says it 
should?)

I tested Python's "email" package, and it definitely doesn't strip this

> BTW, I love the idea of using a public-inbox for comments.

Glad to hear it! I liked what I saw with Drew DeVault's public inbox and 
wanted one for myself. All these years I had essentially been treating 
Disqus as a mailing list, replying to all comments by email, but I was 
constantly frustrated that I couldn't do quoting, and at how it would 
mangle my responses if they were anything more complex than prose.

Inspired by Drew's public inbox, I've just started making use of a 
public inbox myself, so I'm still getting a feel for everything. I 
noticed these two messages aren't threaded together, and I'm curious as 
to the cause:

https://lists.sr.ht/~skeeto/public-inbox/%20%3CDM6PR09MB253761A38B42C713082A7CE2C60C0%40DM6PR09MB2537.namprd09.prod.outlook.com%3E
https://lists.sr.ht/~skeeto/public-inbox/%3C20200122160438.browlclypkwa6wg3%40nullprogram.com%3E

The Message-ID and In-Reply-To match up. I suspect this may be a bug 
based on what I'm seeing in the URL above. The Message-ID header has a 
space following the colon and spans two lines. It seems lists is keeping 
that space in front of the message ID. Note the %20 in the URL above.

Examining my personal email archives (~10k messages), this is the first

At least for me, cgo means giving up some of Go's biggest strengths. 
With the C dependency, cross-compilation and library management is just 
as troublesome as it would be with C. (Yes, I do both often in C.) I 
really like Go and enjoy programming in it, but C is still my personal 
favorite programming language. If I'm going to accept the worst parts of 
C, then I'd rather just do the project in C in the first place.

If you really want to avoid C, then I completely understand how cgo is a 
great tool for doing so.

I agree, those are definitely all downsides to vendoring. I don't think 
it's appropriate for, say, open source projects that are collaborated 
upon over the internet. Though it's a trade-off, and in certain other 
situations — offline development, offline builds, etc. — it's worth 
accepting those downsides. It was one of those situations where I 
learned about "go mod vendor".

In my article I was specifically highlighting the case where you *don't* 
check them into source control, just distribute them in your a release 
tarball, so it has none of the downsides except making the "standalone" 
release tarball bigger. Future archivists would probably love to find 
these kinds of releases.