As other top-level posts have pointed out they're only removing it from the build process, it's still available to users. I wouldn't worry too much about about GCC going away, it's still the default compiler for most (all?) Linux distros.
The source code[1] is quite simple to read (as long as you know Bash) but basically imgcat prints a special OSC[2] sequence (some bytes that tell the terminal to do something special) to stdout followed by the image data which iTerm then handles specially because of the OSC sequence, as far as SSH knows they're just some bytes that it needs to send (no different than running normal cat on a text file). You can kind of think of this as the opposite of what bracketed paste[3] does, in bracketed paste the terminal tells the program to treat some data specially but with imgcat the program tells the terminal to treat some data specially.
This annotation let's the compiler treat their items in special ways, but it is usually for either easier way to refer to them (I want to desugar this type to a cell of what I already have) or for diagnostics. I think box is one of the few "magical" things in the language.
Someone recently did something very stupid/clever with an API that I wrote.
In the code review I initially complained, but then I couldn’t think of any other way to interpret the design. So I guess that’s a feature now. ‘Course later we found a performance problem, but, you know…
> an incomplete microservice migration where you've now got hobbled together half-service weirdware that you have to support forever.
Ugh I have to deal with this at my current job, except it's not an incomplete microservice migration it's by design and comes with a weird hobbled-together event queue implemented as a table in the DB and that has a known race condition that pops up every couple of weeks.
Am I reading that correctly? A porcelain command is one that's not supposed to be used in scripts, but the --porcelain flag is for when you do want to use things in scripts?
> what is the benefit of the line format being character strings? Wouldn't a binary package not be just as easy translatable into human readable JSON formatted output as a compacted JSON string is?
One benefit is that I can look at an arbitrary file/response and be able to tell with a fairly high certainty whether it's JSON, YAML, or TOML, but there's no way that I tell whether it's messagepack, bson, or protobufs.
Most of the time you know the format you expect to decode you don't have to guess it anyway.
But I think you should be able to detect the type of format for binary encodings just as well as there spec is pretty specific. Maybe not at glance as a human, but that is the point I'm making. Should all line formats be made absolute human readable and parsable at glance just to the benefit of debugging at the cost of performance. Where with just a simple lens tool you can look at the data in a completely different (human friendly) view. Tools like this already exist in the form of WireShark, only they mostly operate at a deeper level.
