Live data from Hacker News

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

61–70 of 235 posts

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

#61

I would love to see such post from Microsoft about C#. "We looked into few alternatives and chose our own language, it fitted the task, worked great and came as best overall in terms of technology, devex and maintainability". Great read, thanks for sharing! This means to me you are mature, sharing stuff instead of making obscure secrets from basic stuff existing at many companies <3

They've done quite a few user stories on https://devblogs.microsoft.com/dotnet/category/developer-sto... and related blogs, especially about .NET Framework to .NET migrations.

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

#62
post #57

Earlier quoted context omitted.

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

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

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

#63
post #19
post #15

Any idea of what the server platform is? Linux?

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 incredibly performant and ubiquitous and a very very safe choice.

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

#65
post #37
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.

My $0.02 is that Java not having value types (yet), while Swift has, is a large reason for the efficiency gains.

As a C# dev, I guess I've just taken it for granted that we have value types. Learned something new today (that Java apparently does not).

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

#66

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.

I don’t know that there’s anything that magical about Swift in particular, but rather the difference of running without the big runtime of the JVM and the advantages of memory management. Go will probably give improvements (and likely be an easier mental adjustment from a JVM language), and Rust, once you mentally adapt to its model will give even bigger improvements. Swift has the advantage of being object-oriented (if that’s an advantage in your mind), but I was thinking 10 years ago that with the move to microservices that Java/Spring apps were going to not work so great with the quick start-up/shut-down that the cloud/microservice model wants.

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

#68
post #23

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?

Apple maintains servicetalk[1] (java networking framework built on top of netty), so I'm guessing this is one potential JVM framework that was being used.

[1] https://github.com/apple/servicetalk

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

#69
post #57

Earlier quoted context omitted.

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

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.

But anyway, in this case Apple is making an internal service for themselves. I think a better comparison for MS would be if they chose to rewrite some Windows service’s server back end. Would they choose Go for that?

I don’t know.

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

#70
I wonder what Apple is using for production monitoring, observability, and performance profiling with swift applications on Linux. In my experience this is one of the key missing pieces in Swift server ecosystem.

You can link against jemalloc, and use google perftools to get heap and CPU profiles, but it's challenging to make good use of them especially with swifts method mangling and aggressive inlining.

Post reply on HN