Live data from Hacker News

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

71–80 of 235 posts

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

#71
post #15

Any idea of what the server platform is? Linux?

It's well-known Apple is a big RHEL customer, including Linux on Azure, lending credence to the saying that every Mac is built upon Windows (Hyper-V). Fairly certain the iTunes store, their web store, etc. are all built upon enterprise Linux as well. And there's nothing wrong with that. Use the best tool for the job. Most car owners have never looked in the engine compartment.

I don’t think many azure services are Linux on hyper-v, are they? Azure (afaik) is quite heavy on bare metal Linux.

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

#72
post #15

Any idea of what the server platform is? Linux?

In this case probably Linux, but Apple also uses custom M-series based servers running a hardened Darwin-based OS for LLM processing of user data.

I really really want some kind of write up on that custom m-series hardware. Not very much has even leaked out.

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

#73
post #63
post #19

Earlier quoted context omitted.

Can't really imagine what else it would be.

Apple is known to use Linux on servers, but I could see a case for BSD being in the running. The macOS userland is based on BSD so you’d get a nice little fit there. And it’s not like some common BSD is bad at doing the job of a server. I know it can do great things. Who knows if it was ever discussed. They wouldn’t want Windows (licensing, optics, etc) and macOS isn’t tuned to be a high performance server. Linux is…

Another BSD that Apple used at one point was NetBSD, which is what they ran on their AirPort wireless routers prior to their discontinuation.

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

#75

I understand there may be some bias in this article, but the resource usage improvements are hard to ignore for a company that pays for cloud compute/memory usage. I'm gonna look into server-side Swift. Looks like it'll take some fiddling to find the right non-xcode tools approach for developing on linux. I prefer Jetbrains tools over VSCode, if anyone has any hints in that direction.

Sadly, Jetbrains no longer sells AppCode or supports their Swift plugins for CLion. I WISH they would open source the plugins, as CLion is far superior to Xcode. For now, though, we're really stuck with either Xcode (Mac) or VSCode (wherever). That said, I am really starting to love server-side Swift using Vapor. Swift, as a language, is great to develop in.

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

#76

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

Well, Apple is not gonna use and promote Swift, who will? They surely can't count on you for that role.

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

#77

Earlier quoted context omitted.

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

> Java has had AOT compilation for a while, so traditional GC and its massive overhead are no longer a strict necessity.

You mean it does escape analysis and stack-allocates what it can? That would definitely help, but not eliminate the GC. Or are you thinking of something else?

Thinking about it more, I remember that Java also has some performance-hostile design decisions baked in (e.g. almost everything's an Object, arrays aren't packed, dynamic dispatch everywhere). Swift doesn't have that legacy to deal with.

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

#78
post #42

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.

Swift's limitations around reflection actually make it surprisingly difficult to create a typical Java-style mess with IOC containers and so forth.

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

#79

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, Rust, and C++ all share the same underlying techniques for implementing zero-cost abstrations (primarily, fully-specialized generics). The distinction in Swift's case is that generics can also be executed without specialization (which is what allows generic methods to be called over a stable ABI boundary).

Swift and Rust also allow their protocols to be erased and dispatched dynamically (dyn in Rust, any in Swift). But in both languages that's more of a "when you need it" thing, generics are the preferred tool.

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

#80
post #15

Any idea of what the server platform is? Linux?

It's well-known Apple is a big RHEL customer, including Linux on Azure, lending credence to the saying that every Mac is built upon Windows (Hyper-V). Fairly certain the iTunes store, their web store, etc. are all built upon enterprise Linux as well. And there's nothing wrong with that. Use the best tool for the job. Most car owners have never looked in the engine compartment.

> including Linux on Azure

Are you sure about this?

Post reply on HN