Not an EE, but if transformers are at all like smaller scale power supplies, the issue with using multiple smaller components is it works right up until it doesn't. If you lose one or it gets overloaded, it puts more strain the rest, increasing the failure risk. Then another one pops, and the load shifts to the smaller pool, in a cascade failure.
To an extent, you can do this, as long as you have systems in place to shed load and prevent the components from failing in quick succession by circuit breaking.
Also i believe transformers are much more graceful handling overcurrent than silicon. But everything has its limits.
for one, it's one tool, that does the job of all three.
it just works. i'm not sure how else to describe it other than less faffing about. it just does the right thing, every time. there's a tiny learning curve (mostly unlearning bad or redundant habits), but once you know how to wield it, it's a one stop shop.
Usually lack of knowledge that such a thing exists, or just plain ol' momentum. Changing something long in production at established companies, even if there is a tangible benefit, can be a real challenge.
Standard Italian speakers in Rome struggle to understand Ciociaro dialect, which is from the region on the outskirts of Rome. Take "n'coppa" - spelled with a "c" but very much pronounced /ŋgopa/ with a voiced [g]. I dont even have a reference point for Sicilian but that really pushes the bounds of the dialect/language distinction.
That's one example, from a language with ~70M native speakers, in a geographically tight region.
Likewise, all your other languages (sans Turkiye) are very compact geographically with small speaker bases. And Turkish undoubtedly has large aspects of forced standardization and dialect extinction.
English is spoken by 1.5 billion, by ESL speakers from basically every language tree, across the world. Try to get folks from Boston, Brooklyn, Philly, and Albany in a room and get them to agree on a phonetic spelling.
> Here is the central claim: the unit of correctness in production is not the program. It is the set of deployments.
The thesis essentially boils down to: functional programing paradigm, type systems, strong interfaces, etc, are all fantastic tools for ensuring the correctness of a program, but the system is not a program, and so these tools are necessary but not sufficient to ensure the correctness of a distributed application.
Well, I didn't get LLM vibes from it at all, and the article is deeply relevant to the engineering I am working on at the present (migrating a monolith to a highly event-sourced workflow-based distributed application), and I deeply appreciated this work!
I mean, I am dealing with much of the same problems mentioned in the article, and I found it super enlightening. It was neat to read about undecidability of the general problem of version updates, about the two-version window, and some of the solutions folks have come up with.
Why are folks seemingly so averse to sending an email / hopping on a channel to actually talk to maintainers before just firing off code? I've been on both sides of this; I have been young and green and just fired off contributions without stopping to think, do they event want this?. Codebases are rarely built primarily out of zillions of shotgunned patches, they are more like a garden that needs tending over time, and the ones that are the best tenders are usually the ones that spend the most amount of time in the garden.
To an extent, you can do this, as long as you have systems in place to shed load and prevent the components from failing in quick succession by circuit breaking.
Also i believe transformers are much more graceful handling overcurrent than silicon. But everything has its limits.
reply