Fair enough.

It's ok if you don't feel a need to change your persona workflow.

Nevertheless I'm not sure you understood the example, so I'm not sure you fully grasp the differences.

The whole point of my example was to point out the fact that, thanks to interactive rebase, you do not even need to switch branches to work on multiple unrelated PRs. You can just keep going by doing small commits to your local feature branch and keep doing what you're doing. In the end all you need to do is simply reorder, squash, and even drop commits to put together multiple PRs from commits that are built upon each other.

Simple, and straight to the point.

I think it's hard to provide examples of a binary format beyond a few benchmarks.

Mercure's spec has a bit more meat on its bones in terms of providing an adequate description of the protocol.

From https://mercure.rocks/spec :

Mercure provides a common publish-subscribe mechanism for public and private web resources. Mercure enables the pushing of any web content to web browsers and other clients in a fast, reliable and battery-efficient way. It is especially useful for publishing real-time updates of resources served through sites and web APIs to web and mobile apps.

Subscription requests are relayed through hubs, which validate and verify the request. When new or updated content becomes available, hubs check if subscribers are authorized to receive it then distribute it.

Ergonomic keyboards are not a result of “the size of the keyboard”, but the shape.

I apologize for the mistake. Even though I referred to size, what I had in mind was geometry/layout.

Without any real studies on it mentioned so far you’re relying on gut feeling and logic here.

Are there actually any studies suggesting that ergonomic keyboards prevent RSI? As far as I could gather, there's a correlation between higher RSI incidence and keyboard usage, but nothing suggests ergonomic keyboards lead to a lower incidence of RSI.

Wouldn’t wrist position be considered part of your overall posture?

There are far more factors determining wrist position than the size of the keyboard, and only a very small fraction of all keyboard users end up developing any form of issue.

Moreover, I'd wager that the number of people enduring bad laptop keyboards greatly outnumber those developing any kind of RSI issue, let alone those who feel strongly enough to buy ergonomic keyboards.

It would be interesting to see how many ergonomic keyboards end up being snakeoil preying on people with more disposable money than good judgement.

Walter Bright has fairly odious political opinions;

I fail to see the relevance of what personal opinions and beliefs he may or may not have. You're making it sound like the goal is not to improve a language ir fix issues, but to take something away from a person just because you disagree with their political opinions. That's hardly good use of anyone's time, and sounds terribly petty behavior.

I wish I had that much free time to be able to waste it being so vindictive about such trifling issues.

Which languages have you invested/migrated to, only to find that “political stunts” had a “negative impact” on your planned development?

I don't waste my time with meaningless irrelevant stuff. Either a tech stack serves it's purpose, or it doesn't. I don't have enough free time to waste it trying to cancel others.

Java 18

I can also tell you without any shred of doubt, that there are many Amazon teams that absolutely hate Java

Irrelevant. What matters is what the company uses, not what some guy's personal taste.

Amazon standardizes on Java. There is no way around this fact.

Well, in Rust, it’s a sum-type

The discussion is on to use monads in C++, and not on why is C++ different than Rust.

I repeat: you do not need sum types to implement a Result monad in C++.

I can tell you without any shred of doubt that Amazon still standardizes on Java-based frameworks, including Spring, and has absolutely no plans to switch. Each Amazon team is able to pick its own tech stack, but the ones that do not use Java or a JDK-based stack are extremely rare, and more than not are working on specialized applications such as mobile development.

The only reason Java is remotely tolerable today is because of influences from those ‘fad’ languages.

This might be your personal opinion but it is not a very informed one, or in touch with reality. Java frameworks such as Spring still dominate the backend ecosystem and some FANGs still standardize their backend development around it.