250
points
rhaen
Joined 113 karma
- The majority of the complexity is in the library/executor, rather than in callers. We have an implementation at my company which is now being widely rolled out and it's a pretty dramatic readability win to convert callback based codes to nearly-straight line coroutine code.
- Well, P isn't really much of a choice, I don't think you can opt out of acts of god.
- It's a truly fantastic paper, but like many things the idea that it's impossible to have a perfectly consistent global view of time doesn't mean it's not possible to have a near-perfect one. The blog mentioned AWS's Timesync which lets you be synchronized into the microseconds (https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-ti...), and Google's TrueTime is used to give ranges of times that you're guaranteed to be within (https://cloud.google.com/spanner/docs/true-time-external-con...).
- I'll also note a lot of objections to the way C++ does backwards compatibility is their adherence to an ABI which they refuse to break, but also refuse to say they'll never break.
Many of the problem that can't be fixed for backward compatibility reasons are because they'd break the ABI, not new code. I think that's very different from other language's policy, which, from the ones I'm more familiar with, is about building old and new code together, rather than linking old and new code together.
It makes for a much more restrictive, but also ambiguous and not guaranteed, set of requirements on any change.
- I mean that’s pretty close to a mistake that students make so frequently it has a Wikipedia page https://en.m.wikipedia.org/wiki/Freshman%27s_dream
As a really stupid example: the sets of integers less than 2, 8, 5, and 30 can all be embedded in the set of integers less than 50, but that doesn’t require that the set of integer is finite. You can always get a bigger one that embeds the smaller.