I did some iOS development last year. I did not like the iOS part of it but swift itself feels nice.
Is swift web yet?
Swift at Apple: Migrating the Password Monitoring Service from Java
81–90 of 235 posts
Re: Swift at Apple: Migrating the Password Monitoring Service from Java
#82Earlier quoted context omitted.
I'd typically agree with your comment but ... Given that they also experienced a 90% reduction in Memory Usage (presumably from Java GC vs Swift AOT memory management) - it seems more likely the gains are in fact from the difference in languages.
The typical rule of thumb is that getting good performance out of tracing GC requires doubling your memory usage, so a 90% reduction suggests that they made significant improvements on top of the language switch.
The 90% reduction doesn't necessarily have to be related only to GC.
In my experience Java is a memory hog even compared to other garbage collected languages (that's my main gripe about the language).
I think a good part of the reason is that if you exclude primitive types, almost everything in Java is an heap-allocated object and Java objects are fairly "fat": every single instance has an header of between 96 and 128 bit on 64-bit architectures [1]. That's... a lot. Just by making the headers smaller (the topic of the above link) you can get 20% decrease in heap usage and improvements in cpu and GC time [2].
My hope is that once value classes arrive [3][4], and libraries start to use them, we will see a substantial decrease in heap usage in an average java app.
[1] https://openjdk.org/jeps/450
[2] https://openjdk.org/jeps/519
Re: Swift at Apple: Migrating the Password Monitoring Service from Java
#83> One of the challenges faced by our Java service was its inability to quickly provision and decommission instances due to the overhead of the JVM. ... To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. but this seems to be a totally asynchronous service with extremely liberal latency requirements: > On a regular interval, Password Monitoring checks…
> "why not just run the checks at the backend's discretion?"
Because the other side may not be listening when the compute is done, and you don't want to cache the result of the computation because of privacy.
The sequence of events is:
1. Phone fires off a request to the backend. 2. Phone waits for response from backend.
The gap between 1 and 2 cannot be long because the phone is burning battery the entire time while it's waiting, so there are limits to how long you can reasonably expect the device to wait before it hangs up.
In a less privacy-sensitive architecture you could:
1. Phone fires off request to the backend. Gets a token for response lookup later. 2. Phone checks for a response later with the token.
But that requires the backend to hold onto the response, which for privacy-sensitive applications you don't want!
Re: Swift at Apple: Migrating the Password Monitoring Service from Java
#84Earlier quoted context omitted.
IMO, Apple has quite the track record of never "meeting X where they are". They could make Xcode cross platform, but they never will.
Xcode is probably like, one of the top… 3? 5? biggest macOS-native applications in the world. Making it cross-platform would require either reimplementing it from scratch, or doing a Safari-on-Windows level of shenanigans of reimplementing AppKit on other platforms.
> Safari-on-Windows level of shenanigans of reimplementing AppKit on other platforms
I was curious about this, so I downloaded it to take a look. It doesn't look like they actually shipped AppKit, at least as a separate DLL, but they did ship DLLs for Foundation, Core Graphics, and a few other core macOS frameworks.
Re: Swift at Apple: Migrating the Password Monitoring Service from Java
#85Earlier quoted context omitted.
Imagine what rust or go could have achieved
Go is similar to Swift when it comes to mandatory costly abstractions. It’s only Rust (or C++, but unsafe) that have mostly zero-cost abstractions.
> It’s only Rust (or C++, but unsafe) that have mostly zero-cost abstractions.
This just isn't true. It's good marketing hype for Rust, but any language with an optimizing compiler (JIT or AOT) has plenty of "zero-cost abstractions."
Re: Swift at Apple: Migrating the Password Monitoring Service from Java
#86Without a deeper profiling analysis of the Java application it's hard to not consider this whole piece just advertorial content. Where exactly were the bottlenecks in Java or top delta gains compared to Swift. The service scope looks so simple that there might be some underlying problem with the previous version, be it the code not scaling well with the irregular batch nature of traffic or custom cryptography code not taking advantage of the latest native IO constructs.
And I'm not defending Java by any means, more often than not Java is like an 80s Volvo: incredibly reliable, but you'll spend more time figuring out its strange noises than actually driving it at full speed.
Re: Swift at Apple: Migrating the Password Monitoring Service from Java
#87> In comparison with the previous Java service, the updated backend delivers a 40% increase in performance, along with improved scalability, security, and availability. As is always the case with such rewrites, the big question is whether the improvements came from the choice of language or because they updated a crusty legacy codebase and fixed bugs/bottlenecks.
Yes! The post would have been much more informative if it did an in-depth analysis of where the performance gain comes from. But Apple being Apple, I don't think they'll ever want to expose details on their internal systems, and we probably can only get such hand wavy statements.
I suspect that didn’t fit into the goal of the blog post.
I don’t think it’s meant to be a postmortem on figuring out what was going on and a solution, but more a mini white paper to point out Swift can be used on the server and has some nice benefits there.
So the exact problems with the Java implementation don’t matter past “it’s heavy and slow to start up, even though it does a good job”.
Re: Swift at Apple: Migrating the Password Monitoring Service from Java
#88>Java’s G1 Garbage Collector (GC) mitigated some limitations of earlier collectors The... existing and default GC since JDK 6 G1GC ? >managing garbage collection at scale remains a challenge due to issues like prolonged GC pauses under high loads, increased performance overhead, and the complexity of fine-tuning for diverse workloads. Man if only we had invented other garbage collectors like ZGC ( https://openjdk.org…
Well, Apple is not gonna use and promote Swift, who will? They surely can't count on you for that role.
You can use and promote Swift without being disingenuous.
Swift has some great attributes, and is almost a very pleasant systems language, give or take some sides that can be mostly attributed to Apple going "we need this feature for iOS apps".
An adticle that merely provides some unverifiable claims about how much better it is for them (that represent a large percentage of the best knowledge about Swift on Earth) is about as useful as an AI generated spam site. Anyone making decisions about using Swift on the backend with this post would be a clown.
Re: Swift at Apple: Migrating the Password Monitoring Service from Java
#89Earlier quoted context omitted.
My $0.02 is that Java not having value types (yet), while Swift has, is a large reason for the efficiency gains.
As a C# dev, I guess I've just taken it for granted that we have value types. Learned something new today (that Java apparently does not).
It does for primitives.
For user defined stuff we’ve recently gained records, which are a step in that direction, and a full solution is coming.