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

141–150 of 235 posts

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

#141

Post by jamesfinlayson »

cogman10 wrote: post #137
cellularmitosis wrote: post #131

Earlier quoted context omitted.

If it were such an easy problem to fix, don’t you think they would have done so rather than rewriting in Swift?

Having been in development for a long time, no. Frankly, it just takes some motivated senior devs and the tantalizing ability to put out the OP blog post and you've got something management will sign off on. Bonus points you get to talk about how amazing it was to use Apple tech to get the job done. I don't think they seriously approached this because the article only mentioned tuning G1GC. The fact is, they should h…

Yep, resume-driven development. I remember at a previous company a small group of people pushed a Go rewrite to speed everything up. The serious speed improvements came from re-architecting (elimination of a heavy custom framework, using a message queue instead of handling requests synchronously etc). They would have been better off fixing the original system so that everything could benefit from the improvements, not just the tiny bits that they carved off.

Then the next annual report talked about improved scalability because of this amazing technology from Google.

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

#142

Post by miffy900 »

gorbypark wrote: post #71
dale_huevo wrote: post #49

Earlier quoted context omitted.

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.

Many of their SaaS offerings are, but many infrastructure offerings are running Windows Server underneath. Rent out any Azure VM, and regardless of guest OS, it's using Hyper-v underneath as the hypervisor.

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

#143

Post by tilne »

tialaramex wrote: post #124
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.

Sure, maybe you can get money to have some businesses try out rewriting their line-of-business software in the same language versus in a different language and get some results. My expectation is that if you put the work in you can get actual hard numbers, which will promptly be ignored by every future person asking the same "question" with the same implied answer. If the "just rewrite it and it'll be better" people…

For others that hadn’t head of CADT either: https://www.jwz.org/doc/cadt.html

I confess to having been part of the cascade at various parts of my career.

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

#144

Post by sneak »

> This feature has a server component, running on Linux-based infrastructure, that is maintained by Apple.

Somewhat surprised Apple doesn’t run their services on XNU on internal Xserve-like devices (or work with or contribute to Asahi to get Linux working great natively on all Mx CPUs).

A 1U Mac Studio would be killer. I doubt it’d even be a huge engineering effort given that they’ve already done most of the work for the Studio.

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

#145

Post by dehrmann »

Someone wrote: post #37
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.

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

I would have guessed it's boxed primitives.

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

#146

Post by dhosek »

manmal wrote: post #102
dhosek wrote: post #66

Earlier quoted context omitted.

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…

Will Rust really be better than Swift in such a context? Doesn’t that more or less depend on what kind of memory management is being used in Rust?

The memory management strategies in Rust and Swift are similar. The big performance hit in Swift would come in method dispatch where it’s following Objective C strategies which would result in indirect calls for object methods. This is possible in Rust (using Box(dyn trait)), but discouraged in critical paths in favor of either static dispatch by means of enums or reified calls through Rust generics. Swift has similar capabilities, of course, but with both languages, the best performance reqires consciously making choices in development.

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

#147

Post by selcuka »

cellularmitosis wrote: post #131
javanonymous wrote: post #93

Earlier quoted context omitted.

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

If it were such an easy problem to fix, don’t you think they would have done so rather than rewriting in Swift?

Nothing at IBM is ever straightforward.

Decades ago, I was working with three IBM employees on a client project. During a discussion about a backup solution, one of them suggested that we migrate all customer data into DB2 on a daily basis and then back up the DB2 database.

I asked why we couldn't just back up the client's existing database directly, skipping the migration step. The response? "Because we commercially want to sell DB2."

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

#148

Post by CharlesW »

cogman10 wrote: post #125
CharlesW wrote: post #96

Earlier quoted context omitted.

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

Ok, I'm pretty skeptical that they actually did optimize what they could. In fact, reading between the lines it sounds like they barely tried at all. For example, they mention G1GC as being better than what was originally there but not good enough. Yet the problems they mention, prolonged GC pauses, indicates that G1GC was not the right collector for them. Instead, they should have been using ZGC. The call out of G1G…

As someone who hasn't used Java professionally, this was helpful informed skepticism. Thanks!

> Did they JUST update to java 11?

As an LTS release with "extended" support until 2032, that certainly seems possible.

Another near-certain factor in this decision was that Apple has an extreme, trauma-born abhorrence of critical external dependencies. With "premier" support for 11 LTS having ended last fall, it makes me wonder if a primary lever for this choice was the question of whether it was better to (1) spend time evaluating whether one of Oracle's subsequent Java LTS releases would solve their performance issues, or instead (2) use that time to dogfood server-side Swift (a homegrown, "more open" language that they understand better than anyone in the world) by applying it to a real-world problem at Apple scale, with the goal of eventually replacing all of their Java-based back-ends.

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

#149

Post by miffy900 »

I'm going to call it now: Swift on the backend is pointless for everyone but Apple, and trying to make it takeoff as a backend service language is as pointless as porting Xcode cross platform and trying to lure non-Apple devs into using it over say VSCode, any JetBrains IDE or Visual Studio.

The choices that already serve the market are just too numerous and the existing tooling is already far greater in features, functionality and capability than anything that Apple can provide. What's funny is that they actually have the money to dedicate resources to this space to compete with C#, Java, go or Rust, but they're not going to because it's just too far afield of their core business. Any backend service written in Swift is not going to be running on a Mac in the cloud, and probably won't be serving just iPhone/iPad clients exclusively, so why bother when we know Apple leadership will treat it as an afterthought.

If it does takeoff, I'm betting it will be because the open source community provides a solution, not Apple and even then it will be in a tiny niche. Indeed, this entire project is enabled by Vapor, an open source Swift project that I'm guessing the team only chose because Vapor as a project finally reached the requisite level of maturity for what they wanted. It's not like Apple went out on their own and built their own web framework in Swift, like Microsoft does with C# and ASP.NET. All of this makes me feel even more skeptical about Swift on the backend. Apple won't do anything specifically to give Swift a legup in the backend space, beyond the basics, like porting Swift to linux, but will avail themselves of open source stuff that other people built.

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

#150

Post by MBCook »

latchkey wrote: post #91
MBCook wrote: post #69

Earlier quoted context omitted.

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.

They are certainly far more open these days. I remember when it was Microsoft tools and Microsoft languages on Microsoft servers or nothing.

They’d have never touched Go with a 10 foot poll.

Post reply on HN