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

191–200 of 235 posts

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

#191

Post by throwaway2037 »

dontlaugh wrote: post #58
latchkey wrote: post #54

Earlier quoted context omitted.

Does it matter? Today, they get a 10x improvement by switching. Mission accomplished. X years from now, another language will come along and then they can switch to that for whatever benefit it has. It is just the nature of these things in technology.

It can be a limitation much faster than that. They are in a situation where they won’t be able to improve further by much due to unavoidable costly abstractions in Go. If they’d picked something lower level there would be more possible after this first switch.

FYI: I have no dog in this fight.

    > unavoidable costly abstractions in Go
Can you share some?

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

#192

Post by pjmlp »

geodel wrote: post #166
cogman10 wrote: post #160

Earlier quoted context omitted.

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…

Once Amazon CEO was asked about new competitors trying to create cloud infrastructure fast. His reply was "You cannot compress experience" Saving few weeks or months by learning 3rd party technology instead of applying and improving first party technology would be amateurish. > However, that shouldn't pretend like there was nothing to do to make Java better. This seems like constant refrain that Apple or anyone choos…

I remember the days when Apple developed their own JVM, ported WebObjects from Objective-C to Java, and even had it as the main application language for a little while, uncertain if the Object Pascal/C++ educated developers on their ecosystem would ever bother to learn Objective-C when transitioning to OS X.

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

#193

Post by pjmlp »

sweetjuly wrote: post #135
cogman10 wrote: post #117

Earlier quoted context omitted.

The java GC approach is somewhat unique compared to other languages. There are multiple GCs and pretty much all of them are moving collectors. That means the JVM fairly rarely ends up freeing memory that it's claimed. A big spike will mean that it holds onto the spike's amount of memory. Many other GCed languages, such as swift, CPython, Go, do not use a moving collector. Instead, they allocate and pin memory and fre…

> Many other GCed languages, such as swift Swift is not garbage collected, it uses reference counting. So, memory there is freed immediately when it is no longer in scope.

People really should learn more about CS when discussing these matters.

Chapter 5, https://gchandbook.org/contents.html

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

#194

Post by dwaite »

georgeecollins wrote: post #152
miffy900 wrote: post #149

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.

Rust and Swift share a lot of core concepts.

Swift has a few extra bits for Objective-C compatibility (when running on Apple platforms), but otherwise the biggest differences come to design and ergonomics of the language itself.

If I need complete control over memory for say a web server, or am writing code to run on an embedded device (e.g. without Linux), I'll use Rust - even if Swift technically has the features to meet my needs.

Thats the reverse if I am creating mobile or desktop apps. I'd probably prefer using neither for web services like in this article, but would still probably pick Swift given a limited choice.

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

#195

Post by wiseowise »

CharlesW wrote: post #96
mtrovo wrote: post #86

Without a deeper profiling analysis of the Java application it's hard to not consider this whole piece just advertorial content. Where exactly were the bottlenecks in Java or top delta gains compared to Swift. The service scope looks so simple that there might be some underlying problem with the previous version, be it the code not scaling well with the irregular batch nature of traffic or custom cryptography code no…

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

> TFA makes it clear that they first optimized the Java version as much as it could be under Java's GC

No, it doesn’t.

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

#196

Post by pjmlp »

jeroenhd wrote: post #21
username223 wrote: post #16

Earlier quoted context omitted.

I remember the 2x rule from 20 years ago - do you know if things have changed? If locality is more important now, tracing GC might never be as performant as reference counting. Either you use 2x the memory and thrash your cache, or you use less and spend too much CPU time collecting.

Java has had AOT compilation for a while, so traditional GC and its massive overhead are no longer a strict necessity. Even AOT Java will probably stay behind Swift or any other natively compiled language in terms of memory usage, but it shouldn't be that drastic. As for performance and locality, Java's on-the-fly pointer reordering/compression can give it an edge over even some compiled languages in certain algorith…

For a while means since around 2000, althought toolchains like Excelsior JET and Websphere Real Time, among others, were only available to companies that cared enough to pay for AOT compilers, and JIT caches.

Nowadays to add to your comment, all major free beer implementations, OpenJDK, OpenJ9, GraalVM, and the ART cousin do AOT and JIT caches.

Even without Valhala, there are quite a few tricks possible with Panama, one can manually create C like struct memory layouts.

Yes it is a lot of boilerplate, however one can get around the boilerplate with AI (maybe), or just write the C declarations and point jextract to it.

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

#197

Post by wiseowise »

MBCook wrote: post #69
latchkey wrote: post #62

Earlier quoted context omitted.

Microsoft has a massive investment in C#, but they still evaluated (and picked) golang.

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

You just stated a comment away that Apple chose Swift because of massive investment. Microsoft has much, MUCH bigger investment in C#, but you find all the reason why your original argument is invalid.

The article is just a marketing for a team looking for promo, there’s no deep meaning or larger Apple scheme here.

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

#198

Post by pjmlp »

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.

However you can make use of Panama to work around that, even if it isn't the best experience in the world.

Create C like structs, in regards to memory layout segments, and access them via the Panama APIs.

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

#199

Post by pjmlp »

SigmundA wrote: post #103
MBCook wrote: post #89

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?

Currently only via Panama, creating the memory layout manually in native memory segments.

Valhala is supposed to bring language level support, the biggest issue is how to introduce value types, without breaking the ABI from everything that is in Maven Central kind of.

Similar to the whole async/await engineering effort in .NET Framework, on how to introduce it, without adding new MSIL bytecodes, or requiring new CLR capabilities.

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

#200

Post by pjmlp »

jen20 wrote: post #78
paxys wrote: post #42

Earlier quoted context omitted.

And I'm 100% sure you can do the same in Swift.

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

Post reply on HN