Swift at Apple: migrating the Password Monitoring service from Java

[-]

Pesthuf@reddit

It's a good thing they're dogfooding it and also relying on community projects rather than internal tooling they will never, ever release. I'm a bit skeptical of the 85% reduction in LOC claim - Java is verbose, but not THAT verbose. Same for the massive memory reduction - is Java really THAT wasteful? The old backend must have been absolutely awful code.

I hope the team that made this port can give valuable feedback to the Swift team on what to improve for Swift on servers. But this is Apple, so who knows. Apple secrecy, and all.

[-]

Gogo202@reddit

Java is as wasteful as you write it. It may have more overhead than some other languages, but writing bad code is much more wasteful

[-]

geodel@reddit

Yes Java is that wasteful as does not have value types.

[-]

11T-X-1337@reddit

Java have value types.

[-]

burntcookie90@reddit

thats why?

[-]

SeaworthinessLocal98@reddit

Who would have believed moving from JDK 8 to a modern language and refactoring the entire code base would mean improvement in performance... I'm sure it's because Java sucks /s

[-]

dccorona@reddit

I am confident that nearly all if not all of the advantages touted in this article come from the fact that they rewrote the service, not specifically because they rewrote it in Swift.

[-]

coderemover@reddit

GC pauses, high memory use and long startup times are still a problem in Java. I don’t know much about Swift, but I did a few naive rewrites of some Java to Rust and Rust ran circles around Java.

[-]

simon_o@reddit

Rust and Swift target different niches.

[-]

coderemover@reddit

Not really. Rust doesn’t address any niche, it is a general purpose language, Swift is general purpose too, albeit Swift is likely more limited to apps, while Rust covers apps and systems equally well.

[-]

simon_o@reddit

I didn't ask for your opinion.

[-]

dccorona@reddit

To be honest I would buy the article more if it were about Rust, and if the numbers were more impressive. They got a 40% bump. That’s a far cry from 2x-3x. How much of that could come from tuning and rewrites in Java (which could then be partial)? How much of the rest is worth it considering the engineering cost to do it?

And in return for their they now run a fairly critical service on an at-best nascent and at worst outright experimental server language. One where they had to implement elliptic curve themselves (sure hope they open sourced that part at least). This just does not seem worth the tradeoff to me. Rust perhaps would be. But Apple is a big company and should be able to achieve more business impact by just scaling the fleet up 40% to get the same results and using those engineering hours on something else.

[-]

simon_o@reddit

The whole article sounds a bit desperate to be honest.

I mean, good for them that they found a showcase for Swift, but:

If you talk about G1 giving you some benefits and "in Java, we relied heavily on inheritance" that mainly shows that your primary problem was a sever lack of basic maintenance.

[-]

dccorona@reddit

I had the same thought when they mentioned G1. Even if you assume they only will use LTS JDKs (which is reasonable), they’ve had Shenandoah since 2018 and ZGC since 2021 (and currently have generational ZGC). You don’t at least try those before rewriting the whole service in a different language?

[-]

coderemover@reddit

Don’t forget that Shenandoah and ZGC offer lower pauses at the expense of burning even more CPU than G1. There is no free lunch.

[-]

dccorona@reddit

Fair point but I still think you at least try them. Maybe they did but the text of the article implies they weren’t even considered. “In theory the other GC uses too much CPU to help us” straight into “rewrite the entire thing in a language that we will have to implement our own elliptic curve crypto in because it doesn’t have it yet” is a huge jump.

[-]

simon_o@reddit

This. --^

[-]

Soccer_Vader@reddit

They probably saw this improvements, because they have all these internal tools, that are battle tested and optimized for their use case. It does show Swift as a language is great, great enough for enterprise use cases, but the lack of tooling and community support will always keep it behind Java, Rust and Go for backend use cases.

[-]

blazingkin@reddit

Lmao this is just an ad