Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

Post reply on HN
Print view View original

91–100 of 235 posts

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

#91

Post by latchkey »

MBCook wrote: post #69
latchkey wrote: post #62

Earlier quoted context omitted.

Microsoft has a massive investment in C#, but they still evaluated (and picked) golang.

For TypeScript’s compiler, yes. I can see some real benefits, like Go is already common for some open source software they want to collaborate with non-MS people on. I suspect C# is much less common for that, and when targeting pure performance I suspect a bytecode language like C# wouldn’t have the same large gain. I’m not in the .NET ecosystem so I don’t know if native AOT compilation to machine code is an option.…

The real question isn’t whether they would choose it, but whether they’d be willing to evaluate it. Given their past behavior, as I mentioned above, it seems they are open to assessing options and selecting the best tool for the job.

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

#92

Post by eikenberry »

paxys wrote: post #42
misiek08 wrote: post #30

Earlier quoted context omitted.

I love to always see such comments. On JVM you use crap like Spring and over-engineer everything. 20 types, interfaces and objects to keep single string in memory. JVM also like memory, but can be tailored to look okayish, still worse than opponents.

And I'm 100% sure you can do the same in Swift.

It's not technical, it's cultural. Different community conventions.

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

#93

Post by javanonymous »

tiffanyh wrote: post #8
paxys wrote: 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.

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 JVM tends to use as much memory as it can for performance reasons. It is not a reliable indicator of how much memory it actually needs. Why spend resources on clearing memory if there's still unused memory left?

If memory is an issue, you can set a limit and the JVM will probably still work fine

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

#94

Post by formerly_proven »

mrighele wrote: post #82
plorkyeran wrote: post #10

Earlier quoted context omitted.

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 12…

If Java's 128-bit object headers are already fairly fat, then what adjective applies to CPython's? [] is about a whole cache line. Trivial Python objects are barely smaller.

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

#95

Post by latchkey »

dontlaugh wrote: post #58
latchkey wrote: post #54

Earlier quoted context omitted.

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.

My mistake, I shouldn't have put a number there since that is what you focused on.

Rewriting it in assembly is the way to go, but that has other tradeoffs.

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

#96

Post by CharlesW »

mtrovo wrote: post #86

Without 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 no…

> Without a deeper profiling analysis of the Java application it's hard to not consider this whole piece just advertorial content.

I'd be surprised if anything Apple wrote would satisfy you. TFA makes it clear that they first optimized the Java version as much as it could be under Java's GC, that they evaluated several languages (not just Swift) once it became clear that a rewrite was necessary, that they "benchmarked performance throughout the process of development and deployment", and they shared before/after benchmarks.

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

#97

Post by remus »

favorited wrote: post #27
paxys wrote: 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.

The post notes that the user-facing app was "introduced in the fall of 2024," so presumably the services aren't that legacy.

You can learn a lot when writing V2 of a thing though. You've got lots of real world experience about what worked and what didn't work with the previous design, so lots of opportunity for making data structures that suit the problem more closely and so forth.

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

#98

Post by dontlaugh »

latchkey wrote: post #95
dontlaugh wrote: post #58

Earlier quoted context omitted.

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.

My mistake, I shouldn't have put a number there since that is what you focused on. Rewriting it in assembly is the way to go, but that has other tradeoffs.

I’m not focused on a number, I’m just pointing out Go’s optimisation potential is lower than other options.

Of course it’s a trade off and their reasons are fine, but rewrites are expensive and disruptive. I would have picked something that can avoid a second rewrite later on.

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

#99

Post by time4tea »

Absolute bs.

This falls into the category of "we rewrote a thing written by people that didn't know what they were doing, and it was better"

Large class hierarchies (favour composition over inheritance since 1990!), poorly written async code (not even needed in java, due to virtual threads), poor startup times (probably due to spring), huge heaps sizes (likely memory leaks or other poor code, compounded by inability to restart due to routing and poor startup times)

Yawn.

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

#100

Post by maximilianroos »

potatolicious wrote: post #83
maximilianroos wrote: post #32

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

thanks!
Post reply on HN