Live data from Hacker News

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

211–220 of 235 posts

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

#211

Earlier quoted context omitted.

What about structs?

I'm not sure with the semantics of structs for C#. What java is getting in the future is immutable data values where the reference is the value. When you have something like class Foo { int a; int b; } var c = new Foo(); in java, effectively the representation of `c` is a reference which ultimately points to the heap storage locations of `a, b`. In C++ terms, you could think of the interactions as being `c->b`. When…

This seems like C# `record struct`

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

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

#212
post #120

Earlier quoted context omitted.

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…

> I’ve replaced Java code with Python a few times ... while performance at least doubled Are you saying you made Python code run twice as fast as Java code? I have written lots of both. I really struggle to make Python go fast. What am I doing wrong?

More precisely, when deploying the new service microservice it used less than half as much CPU to process more requests per second.

This is not “Java slow, Python fast” – I expected it to be the reverse – but rather that the developers who cranked out a messy Spring app somehow managed to cancel out all of the work the JVM developers have done without doing anything obviously wrong. There wasn’t a single bottleneck, just death by a thousand cuts with data access patterns, indirection, very deep stack traces, etc.

I have no doubt that there are people here who could’ve rewritten it in better Java for significant wins but the goal with the rewrite was to align a project originally written by a departed team with a larger suite of Python code for the rest of the app, and to deal with various correctness issues. Using Pydantic for the data models not only reduced the amount of code significantly, it flushed out a bunch of inconsistency in the input validation and that’s what I’d been looking for along with reusing our common code libraries for consistency. The performance win was just gravy and, to be clear, I don’t think that’s saying anything about the JVM other than that it does not yet have an optimization to call an LLM to make code less enterprise-y.

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

#213
post #153
post #120

Earlier quoted context omitted.

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.

That’s why I said “culture” - by all rights the JVM should win that competition. I wrote a bit more about the most recent one in a sibling comment but I’d summarize it as “the JVM can’t stop an enterprise Java developer”.

https://news.ycombinator.com/item?id=44179589

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

#214

Earlier quoted context omitted.

Is it really a problem? Client can pass an encryption key with the request and then collect encrypted result later. As long as computation is done and result is encrypted, server can forget the key, so cache is no longer a privacy concern.

You can, and in situations where the computation is unavoidably long that's what you'd do. But if you can do a bit of work to guarantee the computation is fast then it removes a potential failure mode from the system - a particularly nasty one at that. If you forget to dump the key (or if the deletion is not clean) then you've got an absolute whopper of a privacy breach. Also worth noting that you can't dump the key…

„UPDATE checks SET result=?, key=null“

Is it that hard?

Also I don’t think persisting a key generated per task is a big privacy issue.

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

#215
post #190

Earlier quoted context omitted.

Android doesn’t even run JVM. > iPhone comfortably runs with 4GB RAM and Android would be slow as dog. This has nothing to do with RAM. Without load, Android wouldn’t even push 2GB, it would be still slower than iPhone because of different trade-offs they make in architecture.

The point was GC cost in general, not which Java/JVM implementation you choose. Try comparing two Androids with the same chipset at 4GB vs 8GB RAM. Anyhow, that was just an anecdotal unscientific experiment to give you some idea--obviously they are two different codebases. The literature is there to quantify the matter as I noted.

Android for a very long time lacked a quality JIT, AOT and GC implementation, and then each device is a snowflake of whatever changes each OEM has done to the device.

Unless one knows exactly what ART version is installed on the device, what build options from AOSP were used on the firmware image, and what is the mainline version deployed via PlayStore (if on Android 12 or later), there are zero conclusions that one can take out of it.

Also iOS applications tend to just die, when there is no more memory to make use of, due to lack of paging and memory fragmentation.

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

#216
post #213
post #153

Earlier quoted context omitted.

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.

That’s why I said “culture” - by all rights the JVM should win that competition. I wrote a bit more about the most recent one in a sibling comment but I’d summarize it as “the JVM can’t stop an enterprise Java developer”. https://news.ycombinator.com/item?id=44179589

Enterprise developers and architects would be the same, regardless of the programming language.

I am old enough to have seen enterprise C and C++ developers.

Where do you think stuff like DCE, CORBA, DCOM has come from?

Also many of the things people blame Java for, where born as Smalltalk, Objective-C and C++ frameworks before being re-written in Java.

Since we are in a Apple discussion thread, here is some Objective-C ids from Apple frameworks,

https://github.com/Quotation/LongestCocoa

I also advise getting hold of the original WebObjects documentation in Objective-C, before its port to Java.

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

#217
post #200
post #78

Earlier quoted context omitted.

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

Ever heard of Swift macros? Do you know where Java EE comes from? It started as an Objective-C framework, a language which Swift has full interoperability with. https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere

> Ever heard of Swift macros?

Yes, having lived on the daily build bleeding edge of Swift for several years, including while macros were being developed, I have indeed heard of them.

> Do you know where Java EE comes from?

Fully aware of the history.

The point stands: it is substantially harder with Swift to make the kind of spring style mess that JVM apps typically become (of course there are exceptions: I typically suggest people write Java like Martin Thompson instead of Martin Fowler). Furthermore, _people just don’t do it_. I imagine you could visualise the percentage of swift server apps using an IOC container using no hands.

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

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

With the 90% reduction in memory consumption, I'd wager that most if not all the performance improvement came from that. In fact, it is a little surprising that hardware utilization only dropped 50%. Reduced memory consumption for cloud applications was apparently also the primary reason IBM was interested in Swift for a while. Most cloud applications apparently sit mostly idle most of the time, so the number of clie…

The thing about DRAM is that it isn't SRAM; cost matters. You struggle to find deployment environments that have less than 1 GB DRAM available per core, because at that point, ~95% the HW cost is typically CPU anyway. Shrinking that further is kind of pointless, so people don't do it. Hence, when utilizing 16 cores, you get at least 16 GB DRAM that comes with it, whether you choose to use it or not. If you use only 10% of that memory by removing the garbage from the heap, then while lower seems better and all that, it's not necessarily any cheaper in actual memory spending, if both fit within the same minimum 1 GB/core shape you can buy anyway. It might just under utilize the memory resources you paid for in a minimum memory per CPU shape, which isn't necessarily a win. Utilizing the memory you bought isn't wasting it.

Each extra GB per core you add to your shape, actually costs something. Hence every GB/core that can be saved results in actual cost savings. But even then, usually every extra GB/core is ~5% of the CPU cost. Hence, even when going from 10 GB/core (sort of a lot) to 1 GB/core, that only translates to ballpark ~50% less HW cost. Since they did not mention how many cores these instances have, it's hard to know what GB/core were used before and after, and hence whether there were any real cost savings in memory at all, and if so what the relative memory cost savings might have been compared to CPU cost.

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

#219

Earlier quoted context omitted.

I would have guessed it's boxed primitives.

Is that still a thing in 2025? There are so many third party libraries that offer primitive collections. Example: https://github.com/carrotsearch/hppc

If you're not specifically concerned about memory use, why would you use a third-party library?

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

#220
post #172

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…

> they're not going to because it's just too far afield of their core business Apple car was farther?

and it's dead
Post reply on HN