Live data from Hacker News

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

151–160 of 235 posts

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

#151

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

Apple certainly do have web frameworks they’ve written in Swift.

No, I don’t know why they aren’t publicly available (at least yet). But I do know they power a number of public facing services.

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

#152

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

I am really curious what people's take on Hacker News is of Swift. It feels like I heard about it more five years ago. People seem to like Go, Rust is cool (I learned that one), and Python, C#, Java seem here to stay.

I mean I am asking as general purpose language, not just back end.

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

#153
post #120

Earlier quoted context omitted.

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

Java also has a lot of culture making optimization-resistant code so there’s the question of whether you’re talking about the language itself or various widespread libraries, especially if they’re old enough to have patterns designed around aesthetics or now-moot language limitations rather than performance. I’ve replaced Java code with Python a few times and each time even though we did it for maintenance (more Pyth…

That's interesting. I did a line by line rewrite of a large Django route to Quarkus and it was 10x faster, not using async or anything.

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

#154
post #114

Earlier quoted context omitted.

IMO, Apple has quite the track record of never "meeting X where they are". They could make Xcode cross platform, but they never will.

Who even wants Xcode to be cross platform? People can barely tolerate it on macs. What you really mean is people want the iOS development toolchain to be cross platform, and that would mean porting iOS to run in a hypervisor on linux/windows (to get the simulator to work). That is way too big a lift to make sense.

Exactly.

I’ve never wanted Xcode in more places. When I used to be a native mobile dev, I wanted to not have to use Xcode.

And it’s technically possible. But totally not smooth as of a few years ago.

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

#155

Earlier quoted context omitted.

> I don't see any reason to evaluate Go at all. https://devblogs.microsoft.com/typescript/typescript-native-...

That still seems like a long term mistake to me, an evolutionary dead end.

It absolutely was. All it takes is a quick look around other language ecosystems and JS itself.

Rust is an excellent language for embedding in other languages And underpinning developer tools.

That said, someday the new typescript binary will compile to WebAssembly, and it won’t matter much anyway.

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

#156
post #146
post #102

Earlier quoted context omitted.

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

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

While Swift can use Objective-C's message sending to communicate with Objective-C libraries, that isn't its primary dispatch mechanism. In the case of the service described in the article, it isn't even available (since it runs on Linux, which does not have an Objective-C runtime implementation).

Instead, like Rust, Swift's primary dispatch is static by default (either directly on types, or via reified generics), with dynamic dispatch possible via any (which is similar to Rust's dyn). Swift also has vtable-based dispatch when using subclassing, but again this is opt-in like any/dyn is.

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

#157
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’m not even sure those have been turned on tbh

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

#158

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…

If Apple does not dogfood their own technology for production systems what chance do they have to tell 3rd party users that Swift is ready for prime time.

Delving into Java arcana instead of getting first hand experience in developing in Swift would've been great opportunity wasted to improve Swift.

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

#159

Earlier quoted context omitted.

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

Resume driven development would be using some random ass Java framework to pad on resume. Apple using Apple technologies seems rather like corporate mandate.

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

#160
post #158

Earlier quoted context omitted.

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…

If Apple does not dogfood their own technology for production systems what chance do they have to tell 3rd party users that Swift is ready for prime time. Delving into Java arcana instead of getting first hand experience in developing in Swift would've been great opportunity wasted to improve Swift.

I agree if this was a brand new system.

However, they chose to replace an existing system with swift. The "arcana" I mentioned is start up options easily found and safe to apply. It's about as magical as "-O2" is to C++.

Sure, this may have been the right choice if the reason was to exercise swift. However, that shouldn't pretend like there was nothing to do to make Java better. The steps I described are like 1 or 2 days worth of dev work. How much time do you think a rewrite took?

Post reply on HN