>Java’s G1 Garbage Collector (GC) mitigated some limitations of earlier collectors The... existing and default GC since JDK 6 G1GC ? >managing garbage collect

>Java’s G1 Garbage Collector (GC) mitigated some limitations of earlier collectors The... existing and default GC since JDK 6 G1GC ? >managing garbage collection at scale remains a challenge due to issues like prolonged GC pauses under high loads, increased performance overhead, and the complexity of fine-tuning for diverse workloads. Man if only we had invented other garbage collectors like ZGC (https://openjdk.org/jeps/377 https://openjdk.org/jeps/377) since JDK15 or even Shenandoah (https://wiki.openjdk.org/display/shenandoah/Main https://wiki.openjdk.org/display/shenandoah/Main) backported all the way to JDK8 that have goals of sub millisecond GC pauses and scale incredibly well to even terabytes of RAM. Without really a need to tune much of the GC. > inability to quickly provision and decommission instances due to the overhead of the JVM Man if only we invented things like AOT compilation in Java and even native builds. We could call it GraalVM or something (https://www.graalvm.org/ https://www.graalvm.org/) >In Java, we relied heavily on inheritance, which can lead to complex class hierarchies and tight coupling. Man if only you could literally use interfaces the same way you use protocols. Imagine even using a JVM language like Kotlin that provides interface delegation! I guess we'll have to keep shooting ourselves in the foot. >Swift’s optional type and safe unwrapping mechanisms eliminate the need for null checks everywhere, reducing the risk of null pointer exceptions and enhancing code readability. I'll grant them this one. But man, if only NullAway existed :( >Swift’s async/await support is a nice addition, streamlining how we handle async tasks.[ ... ] We can now write async code that reads like sync code Putting aside the fact that Swift's whole MainActor based async story is so shit that I'd enjoy writing async in Rust with tokio and that Swift 6 is the cause of so many headaches because their guidelines on async have been terrible: Man, if only the JDK included things like virtual threads that would make writing async code feel like sync code with a tiny wrapper around. We could call such a thing that collects many threads... A Loom! (https://openjdk.org/projects/loom/ https://openjdk.org/projects/loom/) >Overall, our experience with Swift has been overwhelmingly positive and we were able to finish the rewrite much faster than initially estimated You rewrote an existing service with existing documentation using a language and libraries you entirely control and it was fast ? Wow! >In addition to an excellent support system and tooling, Swift’s inherent emphasis on modularity and extensibility I would rather rewrite all my build scripts in Ant scripts that call `make` manually before calling SPM "excellent tooling", but okay. Anyways, sorry for the sarcasm, but this is just an Apple ad for Apple's Swift Language. Writing low allocation Java code is possible, and while writing efficient arenas is not possible... Java's GC generations are arenas. In the same way, yes, it's more performant. Maybe because their indirection heavy, inheritance abuse led to pointer chasing everywhere, and not having this opportunity in Swift means they can't waste that performance ? Most of what's holding performance back is coding standards and bad habits written at a dark time where the Gang of Four had burrowed its way into every programmer's mind. Add in some reflection for every endpoint because Java back then really loved that for some reason (mostly because writing source generation tasks, or compiler plugins was absolute hell back then, compared to just the "meh" it is today). With a bit of luck, any network serialization also used reflection (thanks GSON & Jackson) and you know just where your throughput has gone. They had extremely verbose, existing Java 8 code, and just decided to rewrite them using Swift because that's most of what happens at Apple these days. Anything outlined in this post is just post-hoc rationalization. Had it failed, this post would have never happened. Modern Java, while still a bit rough in parts (and I absolutely understand preference in language, I'd much rather maintain something I enjoy writing into) can and will absolutely compete in every aspect with Swift. It just requires getting rid of bad habits, that you (cannot/never learned to) write in Swift Also I've never had Java tell me it can't figure out the type of my thirty chained collector calls, so maybe Hindley-Milner was not the place to go.