It's not quite what you're asking for, but Jujutsu+Git is still a much better dev experience than Git alone and is completely compatible with those sites.

I use Jujutsu for 100% of my version control at my day job, where all of our repos are in Bitbucket and all my coworkers are using Git. AFAIK most of my coworkers don't even know I'm doing anything different, other than those who I've "evangelized" so far :)

...I think my PRs have gotten noticeably cleaner and easier to review, though!

To further clarify, I believe Blazor uses SignalR under-the-hood when doing server-side rendering. So the direct answer is probably "this is similar to a component used in Blazor"

Edit: Whoops, I lost context here. Phoenix LiveView as a whole is probably pretty analogous to Blazor.

I wonder if they were thinking of the inner platform effect

This reminds me of some code I stumbled on recently, where someone had implemented a custom exception they could throw if their 32-bit loop counter was greater than the maximum value of a 32-bit integer.

This is getting way outside the traditional compiler model, but I believe the .NET JIT has been adding more support for this in the last couple versions. One aspect of it is covered at https://devblogs.microsoft.com/dotnet/performance-improvemen...

This recent post resonated with me: https://cedardb.com/blog/exceptions_vs_errors/

There are certain obvious (and some less obvious) benefits to both exceptions and results, but I get the impression a lot of programmers have overreacted against exceptions.

Exceptions "just work" the same in every codebase and require little boilerplate in most languages. I think results really shine for internal business logic where errors are more "invalid" than "exceptional."

That's what panics are for. They compile to the same code c++ exceptions would. You can unwrap your results to turn them into exceptions.

While I'm sure most of us have relevant anecdotes for both in-person and videoconferencing, I'm not sure how relevant the circumstances in the study (watching a videoconference lecture) are to typical workplace experiences (participating in a videoconference conversation).

Example #2 suggests that the underlying issue is the function having too many responsibilities. I can't disagree, but the solution conveniently glosses over the fact that the 3 new functions still need to be called from another function, and that function needs a name too!

This can be a useful tension in my experience, since it can indicate when there are too many layers between a program's entry point/composition root and its functionality.

For example, if the three operations in the example are the program's only responsibility, I think the proposed solution makes a lot of sense. But if this is only one step in a program, and especially if that step happens multiple times, having the operations wrapped up in a single function might start to make sense again. I don't quite agree that it's inherently bad code; at some level of abstraction, starting a new worker on a machine starts to look like a single responsibility.