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

201–210 of 235 posts

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

#201

Post by pjmlp »

latchkey wrote: post #47
geodel wrote: post #41

Earlier quoted context omitted.

Swift is Apple's own language. They have all the experts from lowest to highest level . Writing a long winded report/article for fair technical evaluation of competing technologies would utter waste of time and no one would believe if answer were still Swift. > I'd assume Go was among them. ... I don't see any reason to evaluate Go at all.

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

I don't buy the reasoning.

First of all, it is a missed opportunity for Microsoft to have another vector for people to learn C#.

Secondly at BUILD session, Anders ended up explaning that they needed to rewrite the AST data structures anyway, given that Go type system is much inferior to Typescript.

And Go's story on WebAssembly is quite poor, when compared with Blazor toolchain, they are hopping Google will make the necessary improvements, required for the TypeScript playground and when running VSCode on the browser.

Finally, some of the key develpers involved on this effort have been layed off during the latest round.

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

#202

Post by pjmlp »

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

Native AOT is quite good enough nowadays, I think there were other politics at play.

Azure team has no issues using AI to convert from C++ to Rust, see RustNation UK 2025 talks.

Also they mention the reason being a port not a rewrite, yet they had anyway to rewrite the whole AST datastructures due to the weaker typesystem in Go.

Finally, the WebAssembly tooling to support Blazor is much more mature than what Go has.

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

#203

Post by pjmlp »

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.

Fine language for anyone on Apple's ecosystem.

If one rather be OS agnostic, then not so much.

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

#204

Post by pjmlp »

gorbypark wrote: post #71
dale_huevo wrote: post #49

Earlier quoted context omitted.

It's well-known Apple is a big RHEL customer, including Linux on Azure, lending credence to the saying that every Mac is built upon Windows (Hyper-V). Fairly certain the iTunes store, their web store, etc. are all built upon enterprise Linux as well. And there's nothing wrong with that. Use the best tool for the job. Most car owners have never looked in the engine compartment.

I don’t think many azure services are Linux on hyper-v, are they? Azure (afaik) is quite heavy on bare metal Linux.

The OS powering Azure is Windows, even if about 60% of the VMs run Linux workloads, as per official numbers.

https://techcommunity.microsoft.com/blog/windowsosplatform/a...

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

#205

Post by dontlaugh »

hardwaresofton wrote: post #155
dontlaugh wrote: post #53

Earlier quoted context omitted.

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.

There is that opposite approach, yes. Add low-level control to TypeScript and get it to compile to WebAssembly, then the compiler itself can be fast as well.

I suspect they wanted the compiler speed more than they wanted a WASM target, though.

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

#206

Post by dontlaugh »

throwaway2037 wrote: post #191
dontlaugh wrote: post #58

Earlier quoted context omitted.

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?

Implicit struct copies, garbage collection, interface dispatch, etc.

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

#207

Post by cogman10 »

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…

> Yes, there are endless stories companies spending enormous resources to optimize Java stack

And not what I'm advocating for. Sometimes rewrites are necessary.

What I'm advocating is exercising a few well documented and fairly well known jvm flags that aren't particularly fiddly.

The jvm does have endless knobs, most of which you shouldn't touch and instead should let the heuristics do their work. These flags I'm mentioning are not that.

Swapping g1gc for zgc, for example, would have resolved one of their major complaints about GC impact under load. If the live set isn't near the max heap size then pause times are sub millisecond.

> This seems like constant refrain that Apple or anyone choosing their own tech over someone else's owe absolute fair shot to stuff they didn't choose. This is simply not the way world works.

The reason for this refrain is because Java is a very well known tech, easy to hire for (which Amazon that you cite heavily uses). And Apple had already adopted Java and wrote a product with it (I suspect they have several).

I would not be saying any of this if the article was a generic benchmark and comparison of Java with swift. I would not fault Apple for saying "we are rewriting in swift to minimize the number of languages used internally and improve the swift ecosystem".

I'm taking umbridge to them trying to sell this as an absolute necessity because of performance constraints while making questionable statements on the cause.

And, heck, the need to tweak some flags would be a valid thing to call out in the article "we got the performance we wanted with the default compiler options of Swift. To achieve the same thing with Java requires multiple changes from the default settings". I personally don't find it compelling, but it's honest and would sway someone that wants something that "just works" without fiddling.

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

#208

Post by wiseowise »

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.

There was really big excitement about Swift everywhere, but Apple decided not to capitalize on it and hype died off. Swift is pretty much Mac/iOS language and there are no indications that it is going to change anytime soon.

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

#209

Post by mtrovo »

dwaite wrote: post #179
vips7L wrote: post #173

Earlier quoted context omitted.

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.

JDK 24 is not a LTS release, with 1st party support ending in September. It is also 6 1/2 years newer than Java 11. I would imagine many companies would not use anything newer than JDK 21, the latest LTS release.

I don't get your point.

JDK 11 LTS is from 2018 and after that Oracle pushed two LTS releases: JDK 17 in 2021 and JDK 21 in 2023. On top of that Oracle is commited to releasing a LTS every 2 years with the next one planed for later this year.

Using an LTS doesn't mean you have to create applications on the oldest available release, it means that if you target the latest LTS release your application is going to have a predictable and supported runtime for a very long time.

If they had to start a Java 11 project in 2024 that just points to a deeper organizational problem bigger than just GC.

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

#210

Post by manmal »

dhosek wrote: post #146
manmal wrote: 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…

Adding to what the sibling comment from airspeedswift said, there is not ever a need to use dynamic dispatch in Swift outside of iOS apps. Idiomatic apps will have many internal packages/targets that don't even import any Objective-C based libraries and can be compiled and run with just the swift toolchain. You can even inline all your frequent function calls. Idiomatic Swift also uses classes sparingly, and most are ideally declared final.
Post reply on HN