Comparing monthly cloud cost with one-time hardware purchasing cost completely dismisses the latter's long-time cost like people, replacement parts, power, housing, accessories. While I do believe you can run your own hardware much cheaper, there's a lot to consider before making the decision.
From what I can see on the CA/Browser Forum's website (https://cabforum.org/about/membership/members/), there is enough diversity in the forum to represent the Web community as a whole. Trade embargoes issued by a single country would likely not be represented by enough CA/B members to be pushed through the Forum.
I personally sleep much better knowing that e.g. all major browser vendors cooperate on the CA/B (and elsewhere, e.g. the IETF, W3C, ECMA) instead of the biggest one dictating the rules (which, to be fair, happens to a certain degree, e.g. with Chrome leading the way for certain technologies).
I have experience using this back when I worked for a startup that did distribution grid optimization. The specs are unfortunately useless in practice because while the terminology is standardized the actual use of each object and how to relate them is not.
Thus, every tool makes CIM documents slightly differently and there are no guarantees that a document created in one tool will be usable in another
That's why ENTSO-E has just completed a software vendor interoperability workshop. :-) And import/export/validation worked just fine for all participants.
It's just the visitor pattern, taught in software engineering 101. A function that takes a callback function that gets called for each visited value. Nothing strange about it. Many standard library functions such as sync.Map.Range or filepath.Walk have always used it. The new thing is that it now gets easier to use on the caller side.
The sync.Map.Range, filepath.Walk and other similar functions with visitor pattern in standard Go packages will remain there forever because of backwards compatibility. This means that new functions must be added to standard Go packages in order to be able to use them with iterators starting from Go 1.23. This complicates Go without reasonable benefit:
- You need to be able maintaining code with multiple ways to iterate over various collections in standard Go packages.
- You need to spend time on deciding which approach for iteration to use when you write new code.
The acquisition talked about in the original post wasn't much more than a life-saver for the company so in that regard you could call it life-changing in that many of the fine folks I worked with wouldn't have lost their job.
It would have been very very far from what you usually call an exit, though. Nobody would have cashed out, except maybe some of the VCs and I'm not sure if they'd have called it a successful exit in terms of financial win.
[1] https://hub.docker.com/_/postgres#pgdata
[2] https://www.postgresql.org/docs/current/upgrading.html#UPGRA...