You gauge with metrics and profiles, if necessary, and address as needed. You don’t scrutinize every line of code over whether it’s “reasonable” in advance instead of doing things that actually move the needle.
Good callout on the paper reference, but this author gives gives every indication that he’s dead serious in the first paragraph. I don’t think commenters are confused.
Sometimes it’s as simple as finding the hotspot with a profiler and making a simple change to an algorithm or data structure, just like you would do in any language. The amount of handwringing people do about building systems with Python is silly.
Every Python programmer should be thinking about far more important things than low level performance minutiae. Great reference but practically irrelevant except in rare cases where optimization is warranted. If your workload grows to the point where this stuff actually matters, great! Until then it’s a distraction.
“We didn’t have the expertise to build the thing we were building, got in way over our heads, and built a basic POC using legacy technology, which is fine.”
On a trumpet? A clarinet? No, the motions don't simultaneously overlap. The fingering mechanics are slightly different at speed, but you would still start slow while using the higher speed mechanics and tonguing technique, not jump into high speed practice first.
Depends on the instrument. For wind instruments, the motions basically don’t change, and your focus is on synchronizing your mouth with your hands. Tonguing technique is different at high speed but you would typically practice with the same technique at low speed when learning a fast piece.
It's true that there are security issues, but it's also true that they don't want to put any resources into making their XSLT implementation secure. There is strong unstated subtext that a huge motivation is that they simply want to rip this out of Chrome so they don't have to maintain it at all.
The lead dev driving the Chrome deprecation built a wasm polyfill https://github.com/mfreed7/xslt_polyfill. Multiple people proposed in the Github discussions leading up to this that Google simply make the polyfill ship with Chrome as an on-by-default extension that could be disabled in settings, but he wouldn't consider it.
You were supporting the tail end of an era that is universally agreed upon as an ecosystem failure. The internet didn't provide a consistent user experience for developers or for users, it generated mountains of legacy baggage, and it was frustrating for everyone.
Ideally, sure, but that would increase the already enormous burden of building a standards compliant web browser. For a healthy web ecosystem it's important that not only trillion dollar companies can contribute or compete.
I think the main reason you see overwhelming support for anchors is that the existing Actions functionality is typically so cumbersome to implement and often makes it harder to understand a workflow. Anchor syntax is a little esoteric, but otherwise very simple and grokable.
YAML anchors may be a sharp tool but no one is forced to use them. I have written many verbose Github workflows that would have benefited from using anchors, and I am relieved to learn I can clean those up now.
I’m not sure it would since the whole Bluetooth stack is already designed for P2P. Apple’s network is a true mesh though and not point to point. If you share locations with your friends on FindMy using iPhones or AirTags you will get updates via the encrypted mesh network (that includes other peoples’ iPhones) without being connected to a WiFi or cell network.
The FindMy network is already doing this at scale with location data. Offline messaging might be too niche of a use case for Apple but surely they’ve considered it.