171–180 of 235 posts
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'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 car was farther?
Earlier quoted context omitted.
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 wo…
Earlier quoted context omitted.
That's the theory -- a compacting collector will reduce fragmentation and can put linked objects next to each other. On the other hand, a reference count lives in the object, so you're likely using that cache line already when you change it. I don't know which of these is more important on a modern machine, and it probably depends upon the workload.
The problem is memory colocation not RC management. But I agree, it'll likely be workload dependent. One major positive aspect of RC is the execution costs are very predictable. There's little external state which can negatively impact performance (like the GC currently running). The downside is fragmentation and the CPU time required for memory management. If you have an A -> B -> C chain where A is the only owner o…
I suspect this puts greater emphasis on functionality like value types and flexibility in compositionally creating objects. You can trend toward larger objects rather than nesting inner objects for functionality. For example, you can use tagged unions to represent optionality rather than pointers.
The cost of deep A->B->C relationships in Java comes during collections, which still default to be halting. The difference is a reference counting GC will evaluate these chains while removing objects, while a reference tracking GC will evaluate live objects.
So, garbage collection is expensive for ref-counting if you are creating large transient datasets, and is expensive for ref-tracking GC if you are retaining large datasets.
Earlier quoted context omitted.
It does for primitives. For user defined stuff we’ve recently gained records, which are a step in that direction, and a full solution is coming.
What about structs?
Even records are not value-based types, but rather are classes limited to value-like semantics - e.g. they can't extend types, are expected to have immutable behavior by default where modification creates a new record instance, and the like.
The JVM theoretically can perform escape analysis to see that a record behaves a certain way and can be stack allocated, or embedded within the storage of an aggregating object rather than having a separate heap allocation.
A C# struct gets boxed to adapt it to certain things like an Object state parameter on a call. The JVM theoretically would just notice this possibility and decide to make the record heap-allocated from the start.
I say theoretically because I have not tracked if this feature is implemented yet, or what the limitations are if it has been.
> 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.
The post notes that the user-facing app was "introduced in the fall of 2024," so presumably the services aren't that legacy.
I'd like to give server-side Swift a go but it's hard when the best tooling is tied to one platform.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 wo…
Just because it’s supported (receives security updates) doesn’t mean that it isn’t still an ancient and antiquated runtime. Java 11 was released almost 8 years ago. That is thousands of commits and performance improvements behind the latest JDK24.
I would imagine many companies would not use anything newer than JDK 21, the latest LTS release.
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?
And yes, Apple is huge and rich, so they can get fast machines with less memory, but they likely have other tasks with different requirements they want to run on the same hardware.