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

21–30 of 235 posts

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

#21

Post by jeroenhd »

username223 wrote: post #16
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.

I remember the 2x rule from 20 years ago - do you know if things have changed? If locality is more important now, tracing GC might never be as performant as reference counting. Either you use 2x the memory and thrash your cache, or you use less and spend too much CPU time collecting.

Java has had AOT compilation for a while, so traditional GC and its massive overhead are no longer a strict necessity. Even AOT Java will probably stay behind Swift or any other natively compiled language in terms of memory usage, but it shouldn't be that drastic.

As for performance and locality, Java's on-the-fly pointer reordering/compression can give it an edge over even some compiled languages in certain algorithms. Hard to say if that's relevant for whatever web framework Apple based their service on, but I wouldn't discount Java's locality optimisations just because it uses a GC.

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

#23

Post by zapnuk »

Very interesting. I wish they had gone into a little more detail about the other technologies involved.

Was the Java Service in Spring (boot)?

What other technologies were considerd?

I'd assume Go was among them. Was it just the fact that Go's type system is to simplistic or what were the other factors?

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

#24

Post by maz1b »

I've always wondered a slight amount as to why larger enterprises (which have the resources to hire specialists) don't hire people with expertise in say things like Rust, or Elixir/Phoenix?

It's one thing to say that we want to hire commonly available developers like in Java or C#, but if you have a long term plan and execution strategy, why not pick technology that may pay off larger dividends?

ITT: I get why they chose Swift, it's Apple's own in house technology. Makes total sense, not knocking that at all. Nice writeup.

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

#25

Post by geodel »

plorkyeran wrote: post #10
tiffanyh wrote: post #8

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

That is just GC part. Another big difference is Reference type (Java) vs Value Type (Swift).

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

#26

Post by klausa »

candiddevmike wrote: post #6
quux wrote: 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.

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.

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

#27

Post by favorited »

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.

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

#28

Post by geodel »

maz1b wrote: post #24

I've always wondered a slight amount as to why larger enterprises (which have the resources to hire specialists) don't hire people with expertise in say things like Rust, or Elixir/Phoenix? It's one thing to say that we want to hire commonly available developers like in Java or C#, but if you have a long term plan and execution strategy, why not pick technology that may pay off larger dividends? ITT: I get why they c…

Many reasons:

There are not enough Rust experts in the world for a typical enterprise to hire and benefit from it.

Elixir/Phoenix are not order of magnitude improvements over Java like Rust, they are marginal improvements. Enterprise don't care for that.

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

#29

Post by sunnybeetroot »

adamwk wrote: post #17
netbioserror wrote: post #4

A win on the board for ARC? Can anyone with more deep GC knowledge explain why this might be, considering the tweaks they made to G1? Is this a specific workload advantage, or does it apply generally?

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?

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

#30

Post by misiek08 »

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

Post reply on HN