The “Apple only does X better because they do Y” thing has been a meme for ages. I remember dismissals like “PowerPC is only faster at math because it has more integer units” or something along those lines, and thinking, uh, isn’t that a good thing?
There's a qualitative difference between "they're doing a different thing" and "they're doing the same thing, tuned differently". GP is saying that this is a case of "they just tuned it differently".
This distinction doesn't change what the performance numbers look like today, but it does inform what changes would be necessary for those numbers to look different tomorrow. E.g. Apple Silicon isn't fundamentally orders of magnitude more efficient than x86, they just used smaller features. Newer Intel and AMD chips made on equivalent processes _also_ get similar efficiency gains.
There are AMD and Intel devices on similar process (not talking about A20Pro or M6 which are set to ship later this week), and they do not get the same gains.
And honestly, they have historically had different markets.
When the design is for only one customer, you don't need to generalize things, and those things you generalize to give different customers different options has costs.
AMD will soon be a larger customer for TSMC than Apple (NVIDIA is already there) so Apple's pre-booking new processes is likely to be gone in the near future.
I am just saying it's not magic and x86 is capable of doing the same. Quad channel memory used to be more common in consumer hardware but now it looks like you don't even have the option anymore for desktops. AMD's Strix Halo was the first sign to reversing that (it has quad channel memory!) and hopefully we see more of that in the future.
AMD does market segmentation and limits consumer chips to dual-channel. You need to cough up the dough and get Threadripper for quad-channel. Or even more for Threadripper Pro to get octa-channel.
Kind of but not really. DDR5 splits your typical 64-bit channel into two 32-bit subchannels meaning the bus width is not increased. These subchannels are not always advertised because it's a just a feature of DDR5. Actually adding more channels increases bus width, which is what meaningfully improves memory bandwidth.
Confession: Whenever I hear an American say "an historic...", pronouncing the "h", I roll my eyes at the pretense. That's the only word I think I've ever heard someone swap in "an" for "a" before a pronounced consonant.
Now, if they used the British-style "an 'istoric event", that's fine. In American we don't pronounce the "h" in "herb", so someone here saying "an herb garden" would follow the rule correctly and sound normal.
But "history" with the full "h"? To me it screams "this person memorizes without understanding", or at least "this person desperately wants to sound posh but fails". It's the verbal equivalent of wearing a polo shirt with a giant logo, imagining if a tiny one is fancy, then an enormous one must surely be exactly what rich people would wear.
I feel the same way about "an homage". The H is normally pronounced on "homage" - for example, you would not say "pay homage to" with the faux-French pronunciation. So you therefore would say "a homage". It sounds so pretentious when people pronounce it the other way.
thanks for the confession, you are simply guilty of ignorance. I on the other hand am guilty of thinking the English and the French both sound pretentious about pretty much everything: they are both always judging people.
including "The Google Ngram Viewer provides an interesting look at the progress of “an historic” vs “a historic.” In 1800, “a historic” barely shows. It begins its rise in the 1820s. In 1869, “a historic” is neck and neck with “an historic.” The two travel along fairly close together until the First World War when “an historic” pulls ahead and dominates until 1938. After that, “a historic” becomes the clear winner, although “an historic” and “an historical” remain in use. Here are two recent examples of the use of “an historical” in the context of educated English..."
> Style guides like The Chicago Manual of Style, The AP Stylebook, and The Penguin Writer’s Manual regard the following as correct in modern usage:
“a historical event”
“a historic event.”
If you don’t pronounce the h, “an” is the clear winner. Now that most people do in America, “a” is the obviously correct spelling.
I agree. Nginx, Caddy, Apache, etc have found and fixed a million edge cases you'd never think of just from reading and implementing the spec. I guarantee there's code in each of these along the lines of:
# Send an extra 0x20 space character after this header's value, because
# otherwise Chrome on Android 15 shifts into compatibility mode and
# it takes 37x longer to render the page, which everyone will blame on
# "the slow webserver". The spec doesn't say we *can't* add this, and
# tells clients to ignore trailing space, and we've tested this with 483
# other clients to demonstrate that it doesn't cause problems. ¯\_(ツ)_/¯ .
Now, as a very cool hack, or for easier local development with one less dependency, or just to scratch a personal itch and see if it can even be done, right on! That's clever and I'm glad they did it!
BTW, in your showdead (for wholly unclear reasons) comment about it using copy-on-write RAM semantics, that's just the Unix process model. The OS does all that courtesy of fork() and the server gets it for free.
I am, or was. Once, while living there, I wrote a little C program to read a Visual FoxPro database file and write out PostgreSQL commands to load the data. It was for my employer at the time. We needed it for a migration.
And then, a year later, I got invited to a PostgreSQL convention in Brazil where it was one of the tools being quasi-formally recommended to help migrate the country off of VFP.
The world can feel awfully freaking small sometimes.
Bottom line: I look forward to coming to work here every day. If I'm ever the smartest person in the room, I'm in the wrong room. Here, I am definitely in the right room because I get to learn from some brilliant folks.
So, first up: why? Why is everything still using SOAP? I'm not talking down on Brazil, by the way. I've worked in American healthcare tech, and at some point you find yourself learning EDI to talk to insurance companies.
Maybe it's a solved problem and SOAP 1.2 is good enough for that particular job.
We _still_ use TCP/IP and it's v4 is from 1981.
edit: I once looked deep into Remote PowerShell. How it's actually built. Dear. God. XML enveloped inside XML inside another XML wrapped around HTTP. Add some certificate based encryption for the HTTP envelope and some more encryption for the Kerberos messaging inside the serialized XML wrapped in envelopes and wrappings. Now THAT'S a communication protocol. :D
It's a perfectly fine protocol, with a rigid schema and mature code generation support for all relevant languages. It's not the sexiest protocol, but it gets the job done.
> mature code generation support for all relevant languages.
Heh, "relevant languages" is kind of an interesting term there. If the relevant language is Java then sure, it's fine.
Some popular modern languages (ie Go) don't have good SOAP support (yet). At least not to the point of being able to point them at WSDL/XSD specs and have everything auto-generated. :(
That seems like a Go problem. I don't exactly love SOAP and WSDL, but it was the default choice for Java and .Net 10 - 15 years ago in enterprise applications. Given the complexity, rewriting it a few years late, just to switch from a perfectly functional SOAP API to REST makes no sense and would mean that you either run two stack, or force every integrator to rewrite their software.
That's just no how the real world works. When this was launched Go probably wasn't a relevant language, Rust probably barely existed and the whole thing was designed for a corporate setting, where Java and .Net are the standards. All those who are asking "Why SOAP?" or suggests replacing it seems rather naive about how most corporate software is sold, designed, built and maintained, as well as expected lifetimes of solutions.
Eg Python is barely trudging along with random forks of a library that stopped being supported 10 years ago, each fork only getting maintained for about a year at a time.
I really think outside of Java and c#, soap is totally dead.
I think that‘s a matter of days and few hundred dollars in tokens to port it to Go if you really need it.
Porting is where AI can do a really good job with the right instructions.
It's more than just a few days of effort though. Sme of the members of my team at work have been working on adding SOAP 1.1 support. It's a significant amount of time and effort though.
> WSDL/XSD specs in this case seem to be incomplete or just wrong.
Are you meaning in my comment, or in the GitHub repo the article references?
Asking because AFAIK the theory of having (accurate) vendor provided WSDL/XSD files is that you can generate a bunch of code (ie parsers, strong validation) that works with it, generate tests. There are additionally well developed SOAP specific GUIs (ie www.soapui.org) which will directly load the WSDL/XSD files and let you immediately make test network calls to validate things.
Though sure, you can do the above manually without WSDL/XSD files, but if you have accurate ones provided to you by vendors then it makes things a lot easier.
Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services?
Which is also my experience too.
Or have you not dealt with decade+ long services with severe inertia/lockin? Because that is what lets them get away with this.
> Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services?
Correct, yes I haven't.
Other members of staff where I'm working are from Java backgrounds, and have described (in detail) WSDL/XSD (when things are accurate) in positive terms as I put above.
And yeah, I'm presently dealing with vendor specs/docs that don't match what's actually sent over the wire, and it's a huge pain in the arse. And the vendor doesn't give a shit, as like you allude to they're in the telco business so the lock in aspect you mention is correct to. :(
Oh yes, part of the gigantic OASIS UBL (ISO/IEC 19845) and EN 16931 (CEN/TC 434). If young devs today think AI likes to build massive overengineered jargon-filled monstrosities, they should see what they learned it from. Never mind how to get a paycheck, we'll worry about that later, freeing humans from working on this stuff is a humanitarian obligation.
I implemented 837p during the ChangeHealthcare hacks. Once I got the hang of it, it wasn’t too difficult to build a library with OOP that could recursively render itself.
The real difficulty was payers who did not follow the spec, semantically. Whether to include certain fields or not and different interpretations of fields/values was maddening.
SOAP is perfect for integration between organisations (for internal communication other formats is usually better). It supports schema first in a natural way meaning as long as both parties agree on a schema nothing else really need to be shared. XML is mature and supported in all languages with code generation its more or less transparent to the dev.
WS auth is horrible though and a bearer token (and tls) in the header is definitely the way to go.
> XML is mature and supported in all languages with code generation its more or less transparent to the dev.
No, XML is still not mature. They still need to fix the security issues everyone reimplements every time such as local file disclosure via DTDs, exploding documents due to entity expansion and so on. It basically doesn't handle untrusted input well, like SQL built from strings without parameter bindings.
I hope this is reasonable and doesn't use XML Security or similar extensions that add a whole stack of other security issues on top that everyone reimplements when adding SAML support.
> They still need to fix the security issues everyone reimplements every time such as local file disclosure via DTDs, exploding documents due to entity expansion and so on.
Who is doing this reimplementation? You're supposed to be using mature, battle-tested libraries for parsing these formats. Writing your own parser for just about any format is a fool's errand when good implementations that have already addressed these issues exist. Even a simple format like JSON is not immune to performance, safety, and correctness pitfalls.
XML is not perfect, but it is mature. It has been the same for a very long time, all the warts and gotchas are well known. You need to be careful about the same things in 2026 as you did back in 2006.
The answer is probably "because SOAP was the hot new thing when they first decided to do this".
Working with enterprise software is in general a horrific experience, especially that which originated in the 90s at the peak of OOP dogma-cults and insane architecture-astronautism abstraction mixed with SOLIDly thick levels of bureaucracy.
My memories of COM, CORBA, DCE/RPC, XML, etc. are not great. Some of the stuff reads like satire today, but people were actually serious about it: https://en.wikipedia.org/wiki/Object_Management_Group (I recall an article in a physical magazine long ago which started with "The Object Management Group's Working Task Force, also known as OMGWTF...")
Sat in many meetings talking about CORBA and COM. And XML is the gift that just keeps giving. Thank god that stuff is in the rear view mirror.
However in the age of AI I don't know if it matters too much that SOAP is the interchange. It is easy enough to build clients against it. It works. It's probably quite secure. Who cares?
> especially that which originated in the 90s at the peak of OOP dogma-cults and insane architecture-astronautism abstraction mixed with SOLIDly thick levels of bureaucracy.
SOAP is terrible[1], but if the whole country is on board, change is very difficult and you're not going to move to anything simpler because it would either be too simple to actually satisfy the need or too simple to satisfy the selection comittee.
[1] The whole thing with wsdl is like an elaborate prank. Without fail, the WSDL files are impossible to obtain and don't reflect the service as deployed or documented. Documented equivalent forms will not be treated as equivalent. Two instances of a 'standard' service will not accept the same XML. And I only worked with simple SOAP services with straight forward payloads.
Unfortunately that seems like bad history. I’ve only had good experience with wsdls, internally and externally, but they were generated with the services and readily available.
I have the same experience as you. I have probably worked with a few dozen SOAP services in my time, so perhaps I have been "lucky", but WSDLs have not been an issue for me.
WSDL is in some ways more user-friendly than openapi schemas. They have a rich set of types that mostly just work as expected. When I try to generate models from an OpenAPI JSON file, I often find myself either overriding the models or making scripts/plugins to rewrite the json to fix types. An example of this is using proper decimals instead of doubles, which is crucial in my line of work.
I've had positive experiences with wsdls, they offer a lot of advantages over REST/JSON, together with some up front onboarding costs.
It really depends on the service, does it make it easy to obtain the wsdl and more importantly does it honor the type conventions. There is no getting around the fact that services need to maintain consistent behavior and document that behavior, the wsdl is just a transport layer for that organizational commitment. If you have the commitment, then you have a good experience, if you don't, you don't, and whether you are using JSON or SOAP doesn't matter.
That's dramatically overstating it. iOS 26 was just... alright. It wasn't great. It also wasn't the devil incarnate in a phone. iOS 27 has been legimately good since the early public betas.
IBM has always been better than Oracle. It makes giant expensive software and hardware that require arcane knowledge to keep them running. But they also run reliably once you insert enough money.
Oracle's stuff JustDoesn'tWork(tm) once you move past its core database offering. And even that (see: RAC) is sometimes problematic.
reply