Swift at Apple: Migrating the Password Monitoring Service from Java

> 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 a user’s passwords against a continuously updated and curated list of passwords that are known to have been exposed in a leak.

why not just run the checks at the backend's discretion?

I would love to see such post from Microsoft about C#. "We looked into few alternatives and chose our own language, it fitted the task, worked great and came as best overall in terms of technology, devex and maintainability".

Great read, thanks for sharing! This means to me you are mature, sharing stuff instead of making obscure secrets from basic stuff existing at many companies <3

Xcode on Windows/Linux would be wacky and not worth the effort - it's very tightly coupled to MacOS so effectively impossible imho. People targeting MacOS/iOS aren't typically running Windows on the desktop. The more critical thing to meeting developers where they are would be for the entire developer loop to be doable from a JetBrains IDE on MacOS.

>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/jeps/377) since JDK15 or even Shenandoah (https://wiki.openjdk.org/display/shenandoah/Main) backported all the way to JDK8 that have goals of sub millisecond GC pauses and scale incredibly well to even terabytes of RAM. Without really a need to tune much of the GC.

> inability to quickly provision and decommission instances due to the overhead of the JVM

Man if only we invented things like AOT compilation in Java and even native builds. We could call it GraalVM or something (https://www.graalvm.org/)

>In Java, we relied heavily on inheritance, which can lead to complex class hierarchies and tight coupling.

Man if only you could literally use interfaces the same way you use protocols. Imagine even using a JVM language like Kotlin that provides interface delegation! I guess we'll have to keep shooting ourselves in the foot.

>Swift’s optional type and safe unwrapping mechanisms eliminate the need for null checks everywhere, reducing the risk of null pointer exceptions and enhancing code readability.

I'll grant them this one. But man, if only NullAway existed :(

>Swift’s async/await support is a nice addition, streamlining how we handle async tasks.[ ... ] We can now write async code that reads like sync code

Putting aside the fact that Swift's whole MainActor based async story is so shit that I'd enjoy writing async in Rust with tokio and that Swift 6 is the cause of so many headaches because their guidelines on async have been terrible: Man, if only the JDK included things like virtual threads that would make writing async code feel like sync code with a tiny wrapper around. We could call such a thing that collects many threads... A Loom! (https://openjdk.org/projects/loom/)

>Overall, our experience with Swift has been overwhelmingly positive and we were able to finish the rewrite much faster than initially estimated

You rewrote an existing service with existing documentation using a language and libraries you entirely control and it was fast ? Wow!

>In addition to an excellent support system and tooling, Swift’s inherent emphasis on modularity and extensibility

I would rather rewrite all my build scripts in Ant scripts that call `make` manually before calling SPM "excellent tooling", but okay.

Anyways, sorry for the sarcasm, but this is just an Apple ad for Apple's Swift Language. Writing low allocation Java code is possible, and while writing efficient arenas is not possible... Java's GC generations are arenas. In the same way, yes, it's more performant. Maybe because their indirection heavy, inheritance abuse led to pointer chasing everywhere, and not having this opportunity in Swift means they can't waste that performance ? Most of what's holding performance back is coding standards and bad habits written at a dark time where the Gang of Four had burrowed its way into every programmer's mind. Add in some reflection for every endpoint because Java back then really loved that for some reason (mostly because writing source generation tasks, or compiler plugins was absolute hell back then, compared to just the "meh" it is today). With a bit of luck, any network serialization also used reflection (thanks GSON & Jackson) and you know just where your throughput has gone.

They had extremely verbose, existing Java 8 code, and just decided to rewrite them using Swift because that's most of what happens at Apple these days. Anything outlined in this post is just post-hoc rationalization. Had it failed, this post would have never happened. Modern Java, while still a bit rough in parts (and I absolutely understand preference in language, I'd much rather maintain something I enjoy writing into) can and will absolutely compete in every aspect with Swift. It just requires getting rid of bad habits, that you (cannot/never learned to) write in Swift

Also I've never had Java tell me it can't figure out the type of my thirty chained collector calls, so maybe Hindley-Milner was not the place to go.

Swift has an official LSP: https://github.com/swiftlang/sourcekit-lsp

It was first released 7 years ago.