This video doesn't explain what the project does and how it does it. Also it's deliberately misleading the viewer, for example it purposefully incorrectly states that C++ is an interpreted language.

Also the music is way is too loud and sudden.

The video is a compliment to the Github repository, the presenter even shows code and brings up the repo in the video. I guess you didn't watch that part and unfortunately you didn't get the joke either.

Well the video is almost entirely a joke and almost every sentence in it is ironically false; that's the point.

This should have been solved in the last 30 years on Linux console, X terminal emulators and through SSH.

It's more of a "just in case" thing for the most part... the actual risk of an escape as part of a sequence showing up over TCP without the rest for over a fraction of a second today is highly unlikely. That said, so many systems seem to add a delay well over half a second like we're using dialup.

I'd probably tune the delay to 100-200ms if I ever really felt it and have the option to change it.

The kitty key protocol solves this, but your app and terminal need to support it. Many do.

The correct spelling is in lowercase: shared_ptr<T> . The title of the article is correct, the title of the HN post is incorrect.

In hindsight this convention seems weird to me by the way. I didn't question it for the decades I was paid money to write C, but after adopting Rust it jumped out more that it's weird how monocase the C and C++ standard libraries are.

Maybe there's a reason I'd never run into, but this seems like a missed opportunity. Even if I have no idea what Goose is, I can see it's a type, that seems like a win.

Yeah I don't know why so many C programmers ended up on a convention where case is entirely unused. I wonder if it's some ancient compatability thing that they have just been keeping self-consistent with forever. To me not using case is like designing a road map in black-and-white just because you didn't have any ideas for what colors should represent.

I believe HN does that automatically.

How is Areal different from Arial? Neither the article nor https://are.al.are.na/ seem to be informative and focused on this.

https://are.al.are.na/ does include some information on what they changed after tracing the original.

Might as well just quote the one single sentence that gives any specific details:

> Stem thicknesses were streamlined, more characters added, a monospace version drawn, dark mode functionality optimized.

I find this style overy verbose, disrepectful, offensive and dumb. (See example dialogue in the screenshot on the project page.) Fortunately, it's possible to change the prompt above.

I find it hilarious and it made my day.

Half of the source code is colored very-light-on-white, which is impossible to read. I'm using Chrome on Android.

Interesting, and thanks; that's not how it's supposed to look for sure. I'll ask someone to look at the whole mobile experience, definitely not my area.

Supporting arbitrary image formats and compression methods in the browser is easy: just ship the decoder as a WebAssembly function.

(This is not any better solution than GIF or aPNG though for the problem in the article.)

Where are the benchmarks comparing hyperpb to other proto parsers?

The title of the post is misleading, because it is not revealed in the story how the backpack was actually lost. The short summary: ``I don't remember how I lost my backpack, because I was heavily intoxicated during those hours when I lost it.''

The Str_to_double code in the article produces inaccurate results in the last few bits. (What is the use of parsing a double inaccurately?) Accurate parsing of a double is really tricky (and memory-hungry and slow). The strtod(3) function provided by a decent libc (such as glibc and musl, and also the FreeBSD libc) can do it correctly.