Live data from Hacker News

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

51–60 of 235 posts

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#51
post #5

> 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.

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.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#53
post #41

Earlier quoted context omitted.

Swift is Apple's own language. They have all the experts from lowest to highest level . Writing a long winded report/article for fair technical evaluation of competing technologies would utter waste of time and no one would believe if answer were still Swift. > I'd assume Go was among them. ... I don't see any reason to evaluate Go at all.

> I don't see any reason to evaluate Go at all. https://devblogs.microsoft.com/typescript/typescript-native-...

That still seems like a long term mistake to me, an evolutionary dead end.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#54

Earlier quoted context omitted.

> I don't see any reason to evaluate Go at all. https://devblogs.microsoft.com/typescript/typescript-native-...

That still seems like a long term mistake to me, an evolutionary dead end.

Does it matter? Today, they get a 10x improvement by switching. Mission accomplished.

X years from now, another language will come along and then they can switch to that for whatever benefit it has. It is just the nature of these things in technology.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#55
post #2

I'm hoping to hear some good news at WWDC for swift development in editors other than Xcode (VSCode, Neovim, etc.) Last year they said "we need to meet backend developers where they are" and announced plans to improve sourcekit-lsp and other efforts.

Ive wanted this for years. FWIW I've used CLion's Swift plugin for my pure SPM projects and it's actually decent.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#56
post #17

Earlier quoted context omitted.

The way to write performant Swift is classless so without ARC, but classes have been necessary for many areas. Recently, Swift’s been leveraging a lot of ownership features similar to Rust to make it possible to do more without classes, and I’d guess Apple teams would be using those

What areas are classes necessary assuming you’re talking about pure Swift and not iOS?

Where copying is expensive (most Swift collections are backed by classes for COW semantics). Where location stability is necessary (where you need a mutex). Resource allocation. Those are the primary examples that noncopyable types are meant to address.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#57
post #41

Earlier quoted context omitted.

Swift is Apple's own language. They have all the experts from lowest to highest level . Writing a long winded report/article for fair technical evaluation of competing technologies would utter waste of time and no one would believe if answer were still Swift. > I'd assume Go was among them. ... I don't see any reason to evaluate Go at all.

> I don't see any reason to evaluate Go at all. https://devblogs.microsoft.com/typescript/typescript-native-...

But that ignores the fact Apple has a MASSIVE investment in Swift.

I think they already use Go in places, but they’ve clearly stated their intention to use Swift as much as possible where it’s reasonable.

I suspect they didn’t evaluate C++, Rust, Go, Erlang, Node, and 12 other things.

They have the experience from other Swift services to know it will perform well. Their people already know and use it.

If Swift (and the libraries used) weren’t good enough they’d get their people to improve it and then wait to switch off Java.

If you go to a Java shop and say you want to use C# for something Java can do, they’ll probably say to use Java.

I don’t read this post as “Swift is the best thing out there” but simply “hey Swift works great here too where you might not expect, it’s an option you might not have known about”.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#58

Earlier quoted context omitted.

That still seems like a long term mistake to me, an evolutionary dead end.

Does it matter? Today, they get a 10x improvement by switching. Mission accomplished. X years from now, another language will come along and then they can switch to that for whatever benefit it has. It is just the nature of these things in technology.

It can be a limitation much faster than that. They are in a situation where they won’t be able to improve further by much due to unavoidable costly abstractions in Go. If they’d picked something lower level there would be more possible after this first switch.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#59

Earlier 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.

Swift have them too now (non-Copyable types).

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#60

> 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?

Presumably it's a combination of needing to do it while the computer is awake and online, and also the Passwords app probably refreshes the data on launch if it hasn't updated recently.

Post reply on HN