11 ms·

Swift at Apple: Migrating the Password Monitoring Service from Java

243 points by fidotron 1y ago

quux 1y ago
I'm hoping to hear some good news at WWDC for swift development in editors other than Xcode (VSCode, Neovim, etc.) Last year they said "we need to meet backend developers where they are" and announced plans to improve sourcekit-lsp and other efforts.
- sureglymop 1y ago
  I hope so too! We even have an official Kotlin LSP now... maybe that serve as inspiration.
  - rescripting 1y ago
    Swift has an official LSP: https://github.com/swiftlang/sourcekit-lsp https://github.com/swiftlang/sourcekit-lsp It was first released 7 years ago.
    - sureglymop 1y ago
      Thanks for letting me know! I had no idea...
- candiddevmike 1y ago
  IMO, Apple has quite the track record of never "meeting X where they are". They could make Xcode cross platform, but they never will.
  - st3fan 1y ago
    There would be no point in doing that. All the devs they care about already have Macs. If you are on Windows or Linux and you want to work on Swift server side code then you can use their official LSP or VSCode extension in your favorite editor.
    - tough 1y ago
      There's always XTool https://github.com/xtool-org/xtool https://github.com/xtool-org/xtool
  - klausa 1y ago
    Xcode is probably like, one of the top… 3? 5? biggest macOS-native applications in the world. Making it cross-platform would require either reimplementing it from scratch, or doing a Safari-on-Windows level of shenanigans of reimplementing AppKit on other platforms.
    - AdamN 1y ago
      Xcode on Windows/Linux would be wacky and not worth the effort - it's very tightly coupled to MacOS so effectively impossible imho. People targeting MacOS/iOS aren't typically running Windows on the desktop. The more critical thing to meeting developers where they are would be for the entire developer loop to be doable from a JetBrains IDE on MacOS.
      - cosmic_cheese 1y ago
        > People targeting MacOS/iOS aren't typically running Windows on the desktop. Or if they are, they're treating macOS/iOS as “blind targets” where those platforms are rarely if ever QA’d or dogfooded. > The more critical thing to meeting developers where they are would be for the entire developer loop to be doable from a JetBrains IDE on MacOS. I think most current Apple platform devs would be happiest if they were equipped with the tools to build their own IDEs/toolchains/etc, so e.g. Panic's Nova could feasibly have an iOS/macOS/etc dev plugin or someone could turn Sublime Text into a minimalistic Apple platform IDE. JetBrains IDEs certainly have a wide following but among the longtime Mac user devs in particular they’re not seen as quite the panacea they’re presented as in the larger dev community.
    - rafram 1y ago
      > Safari-on-Windows level of shenanigans of reimplementing AppKit on other platforms I was curious about this, so I downloaded it to take a look. It doesn't look like they actually shipped AppKit, at least as a separate DLL, but they did ship DLLs for Foundation, Core Graphics, and a few other core macOS frameworks.
      - quux 1y ago
  - paxys 1y ago
    Who even wants Xcode to be cross platform? People can barely tolerate it on macs. What you really mean is people want the iOS development toolchain to be cross platform, and that would mean porting iOS to run in a hypervisor on linux/windows (to get the simulator to work). That is way too big a lift to make sense.
    - atonse 1y ago
      Exactly. I’ve never wanted Xcode in more places. When I used to be a native mobile dev, I wanted to not have to use Xcode. And it’s technically possible. But totally not smooth as of a few years ago.
- st3fan 1y ago
  This project is getting more mature https://github.com/swiftlang/vscode-swift https://github.com/swiftlang/vscode-swift And https://github.com/swiftlang/sourcekit-lsp https://github.com/swiftlang/sourcekit-lsp an be used in any LSP compatible editor like Neovim.
- lawgimenez 1y ago
  My main wish for Apple this upcoming WWDC is to make Xcode not make my M2 super hot.
- elpakal 1y ago
  Ive wanted this for years. FWIW I've used CLion's Swift plugin for my pure SPM projects and it's actually decent.
- kridsdale1 1y ago
  I’ve been writing iOS apps primarily for 15 years. I haven’t had to use Xcode since about 2016 since Facebook and Google have fully capable VSCode based editors with distributed builds in the Linux clouds. It’s pretty great, but I don’t know of an open source version of this system. That is, integration with Bazel/Buck that can build iOS on non-Mac hardware.
- DavidPiper 1y ago
  Swift SourceKit LSP + VSCode is actually pretty good these days. I recently got it working with CMake for a Swift / CMake project, and the only real pain in that was getting CMake set up properly. Everything else worked out of the box with VSCode's extension manager.
netbioserror 1y ago
A win on the board for ARC? Can anyone with more deep GC knowledge explain why this might be, considering the tweaks they made to G1? Is this a specific workload advantage, or does it apply generally?
- username223 1y ago
  It has been a long time, but I worked on GC at one point. My guess is that it’s the memory footprint (and loss of cache locality) that’s to blame. Copying or mark/sweep can be fast, but only if you give them lots of extra memory to accumulate garbage between GC passes. ARC does a little extra CPU work all the time, but it has good locality, and doesn’t need the extra memory.
- adamwk 1y ago
  The way to write performant Swift is classless so without ARC, but classes have been necessary for many areas. Recently, Swift’s been leveraging a lot of ownership features similar to Rust to make it possible to do more without classes, and I’d guess Apple teams would be using those
  - sunnybeetroot 1y ago
    What areas are classes necessary assuming you’re talking about pure Swift and not iOS?
    - adamwk 1y ago
      Where copying is expensive (most Swift collections are backed by classes for COW semantics). Where location stability is necessary (where you need a mutex). Resource allocation. Those are the primary examples that noncopyable types are meant to address.
      - sunnybeetroot 1y ago
        Ah yes great examples, thank you for explaining.
paxys 1y ago
> 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.
- tiffanyh 1y ago
  I'd typically agree with your comment but ... Given that they also experienced a 90% reduction in Memory Usage (presumably from Java GC vs Swift AOT memory management) - it seems more likely the gains are in fact from the difference in languages.
  - plorkyeran 1y ago
    The typical rule of thumb is that getting good performance out of tracing GC requires doubling your memory usage, so a 90% reduction suggests that they made significant improvements on top of the language switch.
    - username223 1y ago
      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.
      - jeroenhd 1y ago
        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 algorithms. Hard to say if that's relevant for whatever web framework Apple based their service on, but I wouldn't discount Java's locality optimisations just because it uses a GC.
YooLi 1y ago
Any idea of what the server platform is? Linux?
- ezfe 1y ago
  Almost certainly
- paxys 1y ago
  Can't really imagine what else it would be.
  - MBCook 1y ago
    Apple is known to use Linux on servers, but I could see a case for BSD being in the running. The macOS userland is based on BSD so you’d get a nice little fit there. And it’s not like some common BSD is bad at doing the job of a server. I know it can do great things. Who knows if it was ever discussed. They wouldn’t want Windows (licensing, optics, etc) and macOS isn’t tuned to be a high performance server. Linux is incredibly performant and ubiquitous and a very very safe choice.
    - cosmic_cheese 1y ago
      Another BSD that Apple used at one point was NetBSD, which is what they ran on their AirPort wireless routers prior to their discontinuation.
- cosmic_cheese 1y ago
  In this case probably Linux, but Apple also uses custom M-series based servers running a hardened Darwin-based OS for LLM processing of user data.
  - gorbypark 1y ago
    I really really want some kind of write up on that custom m-series hardware. Not very much has even leaked out.
  - 1y ago
deleted 1y ago
[deleted]
zapnuk 1y ago
Very interesting. I wish they had gone into a little more detail about the other technologies involved. Was the Java Service in Spring (boot)? What other technologies were considerd? I'd assume Go was among them. Was it just the fact that Go's type system is to simplistic or what were the other factors?
- geodel 1y ago
  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.
  - latchkey 1y ago
    > I don't see any reason to evaluate Go at all. https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...
    - dontlaugh 1y ago
      That still seems like a long term mistake to me, an evolutionary dead end.
      - latchkey 1y ago
        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.
        dontlaugh 1y ago
        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.
maz1b 1y ago
I've always wondered a slight amount as to why larger enterprises (which have the resources to hire specialists) don't hire people with expertise in say things like Rust, or Elixir/Phoenix? It's one thing to say that we want to hire commonly available developers like in Java or C#, but if you have a long term plan and execution strategy, why not pick technology that may pay off larger dividends? ITT: I get why they chose Swift, it's Apple's own in house technology. Makes total sense, not knocking that at all. Nice writeup.
- geodel 1y ago
  Many reasons: There are not enough Rust experts in the world for a typical enterprise to hire and benefit from it. Elixir/Phoenix are not order of magnitude improvements over Java like Rust, they are marginal improvements. Enterprise don't care for that.
- neepi 1y ago
  It’s because Java and c# are so commoditised we don’t have to pay people as much. Also it’s about short term balance sheet not long term product management in the SME and small SaaS space. I don’t think anyone other then the developers give a shit.
- manmal 1y ago
  They do have Elixir positions, eg https://jobs.apple.com/en-us/details/200562288/senior-software-engineer-elixir-environmental-systems https://jobs.apple.com/en-us/details/200562288/senior-softwa...
- dwaite 1y ago
  it sounds like you are asking why enterprises aren't choosing to write Rust code vs Java code. I wouldn't turn away a developer just because they had experience with Elixir. It really comes down to whether there's someone making the case that a particular application/subsystem has specialized needs that would warrant hiring experts, and whether they can make the case successfully that the system should use technologies that would require additional training and impose additional project risk. Until you are dealing not with enterprise applications but actual services, it can be difficult to even maintain development teams for maintenance - if your one ruby dev leaves, there may be nobody keeping the app running. Even when you are producing services - if they are monolithic, you'll also be strongly encouraged to stick with a single technology stack.
maximilianroos 1y ago
> One of the challenges faced by our Java service was its inability to quickly provision and decommission instances due to the overhead of the JVM. ... To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. but this seems to be a totally asynchronous service with extremely liberal latency requirements: > On a regular interval, Password Monitoring checks a user’s passwords against a continuously updated and curated list of passwords that are known to have been exposed in a leak. why not just run the checks at the backend's discretion?
- deleted 1y ago
  [deleted]
- lilyball 1y ago
  > why not just run the checks at the backend's discretion? Presumably it's a combination of needing to do it while the computer is awake and online, and also the Passwords app probably refreshes the data on launch if it hasn't updated recently.
- potatolicious 1y ago
  > "why not just run the checks at the backend's discretion?" Because the other side may not be listening when the compute is done, and you don't want to cache the result of the computation because of privacy. The sequence of events is: 1. Phone fires off a request to the backend. 2. Phone waits for response from backend. The gap between 1 and 2 cannot be long because the phone is burning battery the entire time while it's waiting, so there are limits to how long you can reasonably expect the device to wait before it hangs up. In a less privacy-sensitive architecture you could: 1. Phone fires off request to the backend. Gets a token for response lookup later. 2. Phone checks for a response later with the token. But that requires the backend to hold onto the response, which for privacy-sensitive applications you don't want!
  - maximilianroos 1y ago
    thanks!
  - 1y ago
misiek08 1y ago
I would love to see such post from Microsoft about C#. "We looked into few alternatives and chose our own language, it fitted the task, worked great and came as best overall in terms of technology, devex and maintainability". Great read, thanks for sharing! This means to me you are mature, sharing stuff instead of making obscure secrets from basic stuff existing at many companies <3
- fmorel 1y ago
  They've done quite a few user stories on https://devblogs.microsoft.com/dotnet/category/developer-stories/ https://devblogs.microsoft.com/dotnet/category/developer-sto... and related blogs, especially about .NET Framework to .NET migrations.
  - metaltyphoon 1y ago
    Not quite the same but close. I assume OP was mentioning from one stack into a completely different one.
ohdeargodno 1y ago
>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.
mring33621 1y ago
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.
- dhosek 1y ago
  I don’t know that there’s anything that magical about Swift in particular, but rather the difference of running without the big runtime of the JVM and the advantages of memory management. Go will probably give improvements (and likely be an easier mental adjustment from a JVM language), and Rust, once you mentally adapt to its model will give even bigger improvements. Swift has the advantage of being object-oriented (if that’s an advantage in your mind), but I was thinking 10 years ago that with the move to microservices that Java/Spring apps were going to not work so great with the quick start-up/shut-down that the cloud/microservice model wants.
  - manmal 1y ago
    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?
    - dhosek 1y ago
      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 similar capabilities, of course, but with both languages, the best performance reqires consciously making choices in development.
      - 1y ago
schlch 1y ago
I did some iOS development last year. I did not like the iOS part of it but swift itself feels nice. Is swift web yet?
latchkey 1y ago
"A faster bootstrap time is a crucial requirement to support this dynamic scaling strategy." Google AppEngine has been doing this successfully for a decade. It is not easy, but it is possible.
sylens 1y ago
I'd like to give server-side Swift a go but it's hard when the best tooling is tied to one platform.
- manmal 1y ago
  In case you mean Xcode with „best tooling“, I‘d disagree. I spend 8h every day with Xcode, and find VSCode often preferable. I‘d just give it a go on Linux tbh.
- t089 1y ago
  Cursor with the official Swift Extension is superior to Xcode for general purpose programming in Swift (even on macOS).
5cott0 1y ago
now fix AppStore Connect
StackRiff 1y ago
I wonder what Apple is using for production monitoring, observability, and performance profiling with swift applications on Linux. In my experience this is one of the key missing pieces in Swift server ecosystem. You can link against jemalloc, and use google perftools to get heap and CPU profiles, but it's challenging to make good use of them especially with swifts method mangling and aggressive inlining.
msie 1y ago
This looks cool except that I see them use Cassandra in their stack. I was using an old version of Cassandra and found it a nightmare to admin.
mtrovo 1y ago
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 not taking advantage of the latest native IO constructs. And I'm not defending Java by any means, more often than not Java is like an 80s Volvo: incredibly reliable, but you'll spend more time figuring out its strange noises than actually driving it at full speed.
- CharlesW 1y ago
  > 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 "benchmarked performance throughout the process of development and deployment", and they shared before/after benchmarks.
  - cogman10 1y ago
    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 G1GC as being "new" is also pretty odd as it was added to the JVM in Java 9, released in 2016. Meaning, they are talking about a 9 year old collector as if it were brand new. Did they JUST update to java 11? And if they are complaining about startup time, then why no mention of AppCDS usage? Or more extreme, CRaC? What about doing an AOT compile with Graal? The only mention they have is the garbage collector, which is simply just one aspect of the JVM. And, not for nothing, the JVM has made pretty humongous strides in startup time and GC performance throughout the versions. Theres pretty large performance wins going from 11->17 and 17->21. I'm sorry, but this really reads as Apple marketing looking for a reason to tout swift as being super great.
time4tea 1y ago
Absolute bs. This falls into the category of "we rewrote a thing written by people that didn't know what they were doing, and it was better" Large class hierarchies (favour composition over inheritance since 1990!), poorly written async code (not even needed in java, due to virtual threads), poor startup times (probably due to spring), huge heaps sizes (likely memory leaks or other poor code, compounded by inability to restart due to routing and poor startup times) Yawn.
jbverschoor 1y ago
The amount of Apple hate is staggering. Replace swift with rust, And this would have 10x the upvotes and only positive hype
- rochak 1y ago
  By now, everyone and their family knows that can get lot of updates just by including Rust in the title. It is what it is.
cogman10 1y ago
I'm honestly very skeptical that Apple actually did everything they could to make Java startup fast and the GC perform well under load. G1GC is a fine collector, but if pause time is really important they should have used ZGC. And if startup is a problem, recent versions of Java have introduced AppCDS which has gotten quite good throughout the releases. And if that wasn't good enough, Graal has for a long time offered AOT compilation which gives you both fast startup and lower memory utilization. None of these things are particularly hard to add into a build pipeline or deployment, they simply require Apple to use the latest version of Java.
artdigital 1y ago
Hearing a company like Apple is using swift on the server side changed my view on server Swift I’ll definitely take a look again, great to see it becoming mature enough to be another viable option
- k_bx 1y ago
  The big questions are: how's package management, community, ease of forking, patching and other dependency management related stuff. Server-side development needs those questions to have good answers.
  - artdigital 1y ago
    Swift has all of that already answered. Non Xcode swift with SwiftPM is solid
    - k_bx 1y ago
      Where's package registry? (crates.io analog) Couldn't find one
      - bhokbah 1y ago
        https://swiftpackageindex.com https://swiftpackageindex.com
sneak 1y ago
> This feature has a server component, running on Linux-based infrastructure, that is maintained by Apple. Somewhat surprised Apple doesn’t run their services on XNU on internal Xserve-like devices (or work with or contribute to Asahi to get Linux working great natively on all Mx CPUs). A 1U Mac Studio would be killer. I doubt it’d even be a huge engineering effort given that they’ve already done most of the work for the Studio.
- MBCook 1y ago
  They are known to use cloud services from Azure (and I assume other providers). If they’re going to run in public clouds + on prem, Linux makes sense. And if you’re doing Linux the x86-64 currently makes a ton of sense too. As you mentioned they’d have to contribute to Asahi, which would take up resources. Even ignoring that the price/performance on Apple hardware in server workloads may not be worth it. Even if it’s slightly better (they don’t pay retail) the fact that it’s a different setup than they run in Azure plus special work to rack them compared to bog-standard 1U PCs, etc may mean it simply isn’t worth it.
miffy900 1y ago
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, functionality and capability than anything that Apple can provide. What's funny is that they actually have the money to dedicate resources to this space to compete with C#, Java, go or Rust, but they're not going to because it's just too far afield of their core business. Any backend service written in Swift is not going to be running on a Mac in the cloud, and probably won't be serving just iPhone/iPad clients exclusively, so why bother when we know Apple leadership will treat it as an afterthought. If it does takeoff, I'm betting it will be because the open source community provides a solution, not Apple and even then it will be in a tiny niche. Indeed, this entire project is enabled by Vapor, an open source Swift project that I'm guessing the team only chose because Vapor as a project finally reached the requisite level of maturity for what they wanted. It's not like Apple went out on their own and built their own web framework in Swift, like Microsoft does with C# and ASP.NET. All of this makes me feel even more skeptical about Swift on the backend. Apple won't do anything specifically to give Swift a legup in the backend space, beyond the basics, like porting Swift to linux, but will avail themselves of open source stuff that other people built.
- jeremymcanally 1y ago
  Apple certainly do have web frameworks they’ve written in Swift. No, I don’t know why they aren’t publicly available (at least yet). But I do know they power a number of public facing services.
- georgeecollins 1y ago
  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.
  - 1y ago
keyle 1y ago
It's nice to see a success story using Vapor and knowing Apple uses Vapor themselves. As a long time Laravel user, which Vapor is inspired from, it gives me hope that Vapor has legs. Swift was a lovely language, up until recently where it should be renamed to Swift++.

243 points by fidotron 1y ago

quux 1y ago

I'm hoping to hear some good news at WWDC for swift development in editors other than Xcode (VSCode, Neovim, etc.) Last year they said "we need to meet backend developers where they are" and announced plans to improve sourcekit-lsp and other efforts.

sureglymop 1y ago
I hope so too! We even have an official Kotlin LSP now... maybe that serve as inspiration.
- rescripting 1y ago
  Swift has an official LSP: https://github.com/swiftlang/sourcekit-lsp https://github.com/swiftlang/sourcekit-lsp It was first released 7 years ago.
  - sureglymop 1y ago
    Thanks for letting me know! I had no idea...
candiddevmike 1y ago
IMO, Apple has quite the track record of never "meeting X where they are". They could make Xcode cross platform, but they never will.
- st3fan 1y ago
  There would be no point in doing that. All the devs they care about already have Macs. If you are on Windows or Linux and you want to work on Swift server side code then you can use their official LSP or VSCode extension in your favorite editor.
  - tough 1y ago
    There's always XTool https://github.com/xtool-org/xtool https://github.com/xtool-org/xtool
- klausa 1y ago
  Xcode is probably like, one of the top… 3? 5? biggest macOS-native applications in the world. Making it cross-platform would require either reimplementing it from scratch, or doing a Safari-on-Windows level of shenanigans of reimplementing AppKit on other platforms.
  - AdamN 1y ago
    Xcode on Windows/Linux would be wacky and not worth the effort - it's very tightly coupled to MacOS so effectively impossible imho. People targeting MacOS/iOS aren't typically running Windows on the desktop. The more critical thing to meeting developers where they are would be for the entire developer loop to be doable from a JetBrains IDE on MacOS.
    - cosmic_cheese 1y ago
      > People targeting MacOS/iOS aren't typically running Windows on the desktop. Or if they are, they're treating macOS/iOS as “blind targets” where those platforms are rarely if ever QA’d or dogfooded. > The more critical thing to meeting developers where they are would be for the entire developer loop to be doable from a JetBrains IDE on MacOS. I think most current Apple platform devs would be happiest if they were equipped with the tools to build their own IDEs/toolchains/etc, so e.g. Panic's Nova could feasibly have an iOS/macOS/etc dev plugin or someone could turn Sublime Text into a minimalistic Apple platform IDE. JetBrains IDEs certainly have a wide following but among the longtime Mac user devs in particular they’re not seen as quite the panacea they’re presented as in the larger dev community.
  - rafram 1y ago
    > Safari-on-Windows level of shenanigans of reimplementing AppKit on other platforms I was curious about this, so I downloaded it to take a look. It doesn't look like they actually shipped AppKit, at least as a separate DLL, but they did ship DLLs for Foundation, Core Graphics, and a few other core macOS frameworks.
    - quux 1y ago
- paxys 1y ago
  Who even wants Xcode to be cross platform? People can barely tolerate it on macs. What you really mean is people want the iOS development toolchain to be cross platform, and that would mean porting iOS to run in a hypervisor on linux/windows (to get the simulator to work). That is way too big a lift to make sense.
  - atonse 1y ago
    Exactly. I’ve never wanted Xcode in more places. When I used to be a native mobile dev, I wanted to not have to use Xcode. And it’s technically possible. But totally not smooth as of a few years ago.
st3fan 1y ago
This project is getting more mature https://github.com/swiftlang/vscode-swift https://github.com/swiftlang/vscode-swift And https://github.com/swiftlang/sourcekit-lsp https://github.com/swiftlang/sourcekit-lsp an be used in any LSP compatible editor like Neovim.
lawgimenez 1y ago
My main wish for Apple this upcoming WWDC is to make Xcode not make my M2 super hot.
elpakal 1y ago
Ive wanted this for years. FWIW I've used CLion's Swift plugin for my pure SPM projects and it's actually decent.
kridsdale1 1y ago
I’ve been writing iOS apps primarily for 15 years. I haven’t had to use Xcode since about 2016 since Facebook and Google have fully capable VSCode based editors with distributed builds in the Linux clouds. It’s pretty great, but I don’t know of an open source version of this system. That is, integration with Bazel/Buck that can build iOS on non-Mac hardware.
DavidPiper 1y ago
Swift SourceKit LSP + VSCode is actually pretty good these days. I recently got it working with CMake for a Swift / CMake project, and the only real pain in that was getting CMake set up properly. Everything else worked out of the box with VSCode's extension manager.

netbioserror 1y ago

A win on the board for ARC? Can anyone with more deep GC knowledge explain why this might be, considering the tweaks they made to G1? Is this a specific workload advantage, or does it apply generally?

username223 1y ago
It has been a long time, but I worked on GC at one point. My guess is that it’s the memory footprint (and loss of cache locality) that’s to blame. Copying or mark/sweep can be fast, but only if you give them lots of extra memory to accumulate garbage between GC passes. ARC does a little extra CPU work all the time, but it has good locality, and doesn’t need the extra memory.
adamwk 1y ago
The way to write performant Swift is classless so without ARC, but classes have been necessary for many areas. Recently, Swift’s been leveraging a lot of ownership features similar to Rust to make it possible to do more without classes, and I’d guess Apple teams would be using those
- sunnybeetroot 1y ago
  What areas are classes necessary assuming you’re talking about pure Swift and not iOS?
  - adamwk 1y ago
    Where copying is expensive (most Swift collections are backed by classes for COW semantics). Where location stability is necessary (where you need a mutex). Resource allocation. Those are the primary examples that noncopyable types are meant to address.
    - sunnybeetroot 1y ago
      Ah yes great examples, thank you for explaining.

paxys 1y ago

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

tiffanyh 1y ago
I'd typically agree with your comment but ... Given that they also experienced a 90% reduction in Memory Usage (presumably from Java GC vs Swift AOT memory management) - it seems more likely the gains are in fact from the difference in languages.
- plorkyeran 1y ago
  The typical rule of thumb is that getting good performance out of tracing GC requires doubling your memory usage, so a 90% reduction suggests that they made significant improvements on top of the language switch.
  - username223 1y ago
    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.
    - jeroenhd 1y ago
      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 algorithms. Hard to say if that's relevant for whatever web framework Apple based their service on, but I wouldn't discount Java's locality optimisations just because it uses a GC.

YooLi 1y ago

Any idea of what the server platform is? Linux?

ezfe 1y ago
Almost certainly
paxys 1y ago
Can't really imagine what else it would be.
- MBCook 1y ago
  Apple is known to use Linux on servers, but I could see a case for BSD being in the running. The macOS userland is based on BSD so you’d get a nice little fit there. And it’s not like some common BSD is bad at doing the job of a server. I know it can do great things. Who knows if it was ever discussed. They wouldn’t want Windows (licensing, optics, etc) and macOS isn’t tuned to be a high performance server. Linux is incredibly performant and ubiquitous and a very very safe choice.
  - cosmic_cheese 1y ago
    Another BSD that Apple used at one point was NetBSD, which is what they ran on their AirPort wireless routers prior to their discontinuation.
cosmic_cheese 1y ago
In this case probably Linux, but Apple also uses custom M-series based servers running a hardened Darwin-based OS for LLM processing of user data.
- gorbypark 1y ago
  I really really want some kind of write up on that custom m-series hardware. Not very much has even leaked out.
- 1y ago

deleted 1y ago

[deleted]

zapnuk 1y ago

Very interesting. I wish they had gone into a little more detail about the other technologies involved. Was the Java Service in Spring (boot)? What other technologies were considerd? I'd assume Go was among them. Was it just the fact that Go's type system is to simplistic or what were the other factors?

geodel 1y ago
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.
- latchkey 1y ago
  > I don't see any reason to evaluate Go at all. https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...
  - dontlaugh 1y ago
    That still seems like a long term mistake to me, an evolutionary dead end.
    - latchkey 1y ago
      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.
      - dontlaugh 1y ago
        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.

maz1b 1y ago

I've always wondered a slight amount as to why larger enterprises (which have the resources to hire specialists) don't hire people with expertise in say things like Rust, or Elixir/Phoenix? It's one thing to say that we want to hire commonly available developers like in Java or C#, but if you have a long term plan and execution strategy, why not pick technology that may pay off larger dividends? ITT: I get why they chose Swift, it's Apple's own in house technology. Makes total sense, not knocking that at all. Nice writeup.

geodel 1y ago
Many reasons: There are not enough Rust experts in the world for a typical enterprise to hire and benefit from it. Elixir/Phoenix are not order of magnitude improvements over Java like Rust, they are marginal improvements. Enterprise don't care for that.
neepi 1y ago
It’s because Java and c# are so commoditised we don’t have to pay people as much. Also it’s about short term balance sheet not long term product management in the SME and small SaaS space. I don’t think anyone other then the developers give a shit.
manmal 1y ago
They do have Elixir positions, eg https://jobs.apple.com/en-us/details/200562288/senior-software-engineer-elixir-environmental-systems https://jobs.apple.com/en-us/details/200562288/senior-softwa...
dwaite 1y ago
it sounds like you are asking why enterprises aren't choosing to write Rust code vs Java code. I wouldn't turn away a developer just because they had experience with Elixir. It really comes down to whether there's someone making the case that a particular application/subsystem has specialized needs that would warrant hiring experts, and whether they can make the case successfully that the system should use technologies that would require additional training and impose additional project risk. Until you are dealing not with enterprise applications but actual services, it can be difficult to even maintain development teams for maintenance - if your one ruby dev leaves, there may be nobody keeping the app running. Even when you are producing services - if they are monolithic, you'll also be strongly encouraged to stick with a single technology stack.

maximilianroos 1y ago

> One of the challenges faced by our Java service was its inability to quickly provision and decommission instances due to the overhead of the JVM. ... To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. but this seems to be a totally asynchronous service with extremely liberal latency requirements: > On a regular interval, Password Monitoring checks a user’s passwords against a continuously updated and curated list of passwords that are known to have been exposed in a leak. why not just run the checks at the backend's discretion?

deleted 1y ago
[deleted]
lilyball 1y ago
> why not just run the checks at the backend's discretion? Presumably it's a combination of needing to do it while the computer is awake and online, and also the Passwords app probably refreshes the data on launch if it hasn't updated recently.
potatolicious 1y ago
> "why not just run the checks at the backend's discretion?" Because the other side may not be listening when the compute is done, and you don't want to cache the result of the computation because of privacy. The sequence of events is: 1. Phone fires off a request to the backend. 2. Phone waits for response from backend. The gap between 1 and 2 cannot be long because the phone is burning battery the entire time while it's waiting, so there are limits to how long you can reasonably expect the device to wait before it hangs up. In a less privacy-sensitive architecture you could: 1. Phone fires off request to the backend. Gets a token for response lookup later. 2. Phone checks for a response later with the token. But that requires the backend to hold onto the response, which for privacy-sensitive applications you don't want!
- maximilianroos 1y ago
  thanks!
- 1y ago

misiek08 1y ago

I would love to see such post from Microsoft about C#. "We looked into few alternatives and chose our own language, it fitted the task, worked great and came as best overall in terms of technology, devex and maintainability". Great read, thanks for sharing! This means to me you are mature, sharing stuff instead of making obscure secrets from basic stuff existing at many companies <3

fmorel 1y ago
They've done quite a few user stories on https://devblogs.microsoft.com/dotnet/category/developer-stories/ https://devblogs.microsoft.com/dotnet/category/developer-sto... and related blogs, especially about .NET Framework to .NET migrations.
- metaltyphoon 1y ago
  Not quite the same but close. I assume OP was mentioning from one stack into a completely different one.

ohdeargodno 1y ago

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

mring33621 1y ago

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.

dhosek 1y ago
I don’t know that there’s anything that magical about Swift in particular, but rather the difference of running without the big runtime of the JVM and the advantages of memory management. Go will probably give improvements (and likely be an easier mental adjustment from a JVM language), and Rust, once you mentally adapt to its model will give even bigger improvements. Swift has the advantage of being object-oriented (if that’s an advantage in your mind), but I was thinking 10 years ago that with the move to microservices that Java/Spring apps were going to not work so great with the quick start-up/shut-down that the cloud/microservice model wants.
- manmal 1y ago
  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?
  - dhosek 1y ago
    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 similar capabilities, of course, but with both languages, the best performance reqires consciously making choices in development.
    - 1y ago

schlch 1y ago

I did some iOS development last year. I did not like the iOS part of it but swift itself feels nice. Is swift web yet?

latchkey 1y ago

"A faster bootstrap time is a crucial requirement to support this dynamic scaling strategy." Google AppEngine has been doing this successfully for a decade. It is not easy, but it is possible.

sylens 1y ago

I'd like to give server-side Swift a go but it's hard when the best tooling is tied to one platform.

manmal 1y ago
In case you mean Xcode with „best tooling“, I‘d disagree. I spend 8h every day with Xcode, and find VSCode often preferable. I‘d just give it a go on Linux tbh.
t089 1y ago
Cursor with the official Swift Extension is superior to Xcode for general purpose programming in Swift (even on macOS).

5cott0 1y ago

now fix AppStore Connect

StackRiff 1y ago

I wonder what Apple is using for production monitoring, observability, and performance profiling with swift applications on Linux. In my experience this is one of the key missing pieces in Swift server ecosystem. You can link against jemalloc, and use google perftools to get heap and CPU profiles, but it's challenging to make good use of them especially with swifts method mangling and aggressive inlining.

msie 1y ago

This looks cool except that I see them use Cassandra in their stack. I was using an old version of Cassandra and found it a nightmare to admin.

mtrovo 1y ago

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 not taking advantage of the latest native IO constructs. And I'm not defending Java by any means, more often than not Java is like an 80s Volvo: incredibly reliable, but you'll spend more time figuring out its strange noises than actually driving it at full speed.

CharlesW 1y ago
> 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 "benchmarked performance throughout the process of development and deployment", and they shared before/after benchmarks.
- cogman10 1y ago
  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 G1GC as being "new" is also pretty odd as it was added to the JVM in Java 9, released in 2016. Meaning, they are talking about a 9 year old collector as if it were brand new. Did they JUST update to java 11? And if they are complaining about startup time, then why no mention of AppCDS usage? Or more extreme, CRaC? What about doing an AOT compile with Graal? The only mention they have is the garbage collector, which is simply just one aspect of the JVM. And, not for nothing, the JVM has made pretty humongous strides in startup time and GC performance throughout the versions. Theres pretty large performance wins going from 11->17 and 17->21. I'm sorry, but this really reads as Apple marketing looking for a reason to tout swift as being super great.

time4tea 1y ago

Absolute bs. This falls into the category of "we rewrote a thing written by people that didn't know what they were doing, and it was better" Large class hierarchies (favour composition over inheritance since 1990!), poorly written async code (not even needed in java, due to virtual threads), poor startup times (probably due to spring), huge heaps sizes (likely memory leaks or other poor code, compounded by inability to restart due to routing and poor startup times) Yawn.

jbverschoor 1y ago

The amount of Apple hate is staggering. Replace swift with rust, And this would have 10x the upvotes and only positive hype

rochak 1y ago
By now, everyone and their family knows that can get lot of updates just by including Rust in the title. It is what it is.

cogman10 1y ago

I'm honestly very skeptical that Apple actually did everything they could to make Java startup fast and the GC perform well under load. G1GC is a fine collector, but if pause time is really important they should have used ZGC. And if startup is a problem, recent versions of Java have introduced AppCDS which has gotten quite good throughout the releases. And if that wasn't good enough, Graal has for a long time offered AOT compilation which gives you both fast startup and lower memory utilization. None of these things are particularly hard to add into a build pipeline or deployment, they simply require Apple to use the latest version of Java.

artdigital 1y ago

Hearing a company like Apple is using swift on the server side changed my view on server Swift I’ll definitely take a look again, great to see it becoming mature enough to be another viable option

k_bx 1y ago
The big questions are: how's package management, community, ease of forking, patching and other dependency management related stuff. Server-side development needs those questions to have good answers.
- artdigital 1y ago
  Swift has all of that already answered. Non Xcode swift with SwiftPM is solid
  - k_bx 1y ago
    Where's package registry? (crates.io analog) Couldn't find one
    - bhokbah 1y ago
      https://swiftpackageindex.com https://swiftpackageindex.com

sneak 1y ago

> This feature has a server component, running on Linux-based infrastructure, that is maintained by Apple. Somewhat surprised Apple doesn’t run their services on XNU on internal Xserve-like devices (or work with or contribute to Asahi to get Linux working great natively on all Mx CPUs). A 1U Mac Studio would be killer. I doubt it’d even be a huge engineering effort given that they’ve already done most of the work for the Studio.

MBCook 1y ago
They are known to use cloud services from Azure (and I assume other providers). If they’re going to run in public clouds + on prem, Linux makes sense. And if you’re doing Linux the x86-64 currently makes a ton of sense too. As you mentioned they’d have to contribute to Asahi, which would take up resources. Even ignoring that the price/performance on Apple hardware in server workloads may not be worth it. Even if it’s slightly better (they don’t pay retail) the fact that it’s a different setup than they run in Azure plus special work to rack them compared to bog-standard 1U PCs, etc may mean it simply isn’t worth it.

miffy900 1y ago

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, functionality and capability than anything that Apple can provide. What's funny is that they actually have the money to dedicate resources to this space to compete with C#, Java, go or Rust, but they're not going to because it's just too far afield of their core business. Any backend service written in Swift is not going to be running on a Mac in the cloud, and probably won't be serving just iPhone/iPad clients exclusively, so why bother when we know Apple leadership will treat it as an afterthought. If it does takeoff, I'm betting it will be because the open source community provides a solution, not Apple and even then it will be in a tiny niche. Indeed, this entire project is enabled by Vapor, an open source Swift project that I'm guessing the team only chose because Vapor as a project finally reached the requisite level of maturity for what they wanted. It's not like Apple went out on their own and built their own web framework in Swift, like Microsoft does with C# and ASP.NET. All of this makes me feel even more skeptical about Swift on the backend. Apple won't do anything specifically to give Swift a legup in the backend space, beyond the basics, like porting Swift to linux, but will avail themselves of open source stuff that other people built.

jeremymcanally 1y ago
Apple certainly do have web frameworks they’ve written in Swift. No, I don’t know why they aren’t publicly available (at least yet). But I do know they power a number of public facing services.
georgeecollins 1y ago
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.
- 1y ago

keyle 1y ago

It's nice to see a success story using Vapor and knowing Apple uses Vapor themselves. As a long time Laravel user, which Vapor is inspired from, it gives me hope that Vapor has legs. Swift was a lovely language, up until recently where it should be renamed to Swift++.