A better way to profile multithreaded programs

That can definitely be true, but note lots of things are latency-, not throughput-bound. In particular, microservice-based systems are likely to hit 99% latency of some service on (many/most/all) requests; I'd expect that a similar trick would be helpful there.

Actually, Coz lets you profile for latency and throughput. That's one of its main points.

Not really standard, but also not unheard of. Google "css only shapes" for examples.

Top hit is https://css-tricks.com/examples/ShapesOfCSS/, which has several examples of before: and after: use to create, for example, a five-pointed star.

Or Erlang/Elixir, which I found simpler than Go (though that may be due to my experience with Erlang, and my tending to think in Erlang ways, and it not quite matching Go's). Certainly, the guaranteed immutability, better pre-emptive scheduling, supervision, easy distribution of processes across multiple nodes, and better process isolation meant I felt my code was more reliable than with Go.

EDIT: Since you didn't mention Erlang, just to give you a point of reference, Erlang message passing is directly between lightweight processes, rather than an intermediate channel like in Go. I've heard people reference it as files vs file descriptors, but for myself, I think of it architecturally. Go creates an abstraction for the message type, that is, create a channel for ~this~ kind of message, and pub/sub to it as needed, and you shouldn't have to care about who is subscribed to determine what channel to publish on (it's enough to say 'it's this kind of message, so it goes on this channel'). Erlang, on the other hand (and Elixir) send messages directly to different processes, no additional abstraction. As such, you end up thinking about who needs to communicate with who, and how best to do that. So by default, it's like having a channel with exactly one known listener. Of course, you can easily build a channel like behavior, by creating a process whose sole job is to collect messages, and determine how to federate them out to other subscribed processes. I prefer the Erlang way because oftentimes the level of abstraction Go gives is unnecessary (and sometimes even a source of bugs, where I did a poor job of defining my messages, and not thinking about who was listening to the channel meant that a process got a message that it should not have, because of another, similarly typed message that it should have; I needed two channels, but created only one), but when it's useful I can always easily build it in.