Hurray for micro benchmarks. Anyway, every language can be abused. I can make Java run slower than Ruby. Given that it runs on Microcontrollers on billions of devices, I don't think Swift is necessarily the problem in whatever case you have in mind (And yes I stole oracle's java marketing there for Swift, it is true though.)
They do run Apple Silicon in data centers, so perhaps another custom version of Darwin + their system frameworks. It is hard to tell without some leaks :)
For Private Cloud Compute: “a new operating system: a hardened subset of the foundations of iOS and macOS tailored to support Large Language Model (LLM) inference workloads while presenting an extremely narrow attack surface.” https://security.apple.com/blog/private-cloud-compute/
I think you are failing to realize the billions the US has made from "defending" europe. Regardless, once the US is no longer colonizing the entire planet and the dollar isn't the only currency anyone cares about your opinion will change realllll quick. You'll have forgotten this wall of nonsense you wrote though by then I'm sure.
This makes me think you haven't really tried it ever? Sure writing a hello world is something but, one of the best features of Swift on the server side is that it seamlessly interopts with anything C (and nowadays C++, though that is after my time).
I wrote an entire, well performing backend in Swift because I could just directly plug in to already existing libraries without having ot provide a whole bunch of "FFI" glue.
All the other languages you suggest is something that Swift excels at while staying performant (also none of those have an IDE like Xcode so idk why you even bring it up). Though for actual systems programming I don't think Rust can be beaten by Swift, simply because of its more explicit (and therefore confronting) nature.
We use server side Swift extensively since about 2016 for decent production load and it's easily one of the worst decisions I've ever made.
- C/C++ interop is great but if we wanted to use C/C++ libraries why use Swift at all? It's annoying to interop with them even if there is no FFI and still requires a lot of glue code for memory management etc…
- The stdlib (Foundation) is not identical on all platforms even today. This has been a major thorn as releases constantly have discrepancies and subtle bugs that are hard to diagnose and track down. Even Swift 6.1 broke non UTF-8 string encodings by just returning "nil" on Linux and took until Swift 6.2 to be fixed (nearly a year).
- The compile times are awful, with a large Swift codebase it takes us ~10-20 minutes to compile our backend Docker container and thus deployments to dev take that long and it's only going to keep getting longer as Apple seemingly has no interest in making the Swift toolchain much faster and Swift has a fatal flaw in it's design around bi-directional type inference that ensure it can never be compiled fast.
- Talent is impossible to find. Yes lots of people know Swift for iOS apps but nobody knows Swift for server code and a backend dev is a very different skillset than an app dev.
We chose it because it allowed us to share some domain code between our flagship iOS product and the server with a custom built sync engine but as our platform has grown it's just gotten harder and harder to justify keeping Swift on the server which is why we're actively migrating off it.
> - The stdlib (Foundation) is not identical on all platforms even today. This has been a major thorn as releases constantly have discrepancies and subtle bugs that are hard to diagnose and track down. Even Swift 6.1 broke non UTF-8 string encodings by just returning "nil" on Linux and took until Swift 6.2 to be fixed (nearly a year).
sad, I was doing server side around v4/5 and this was the biggest issue at the time for me (lots of stuff was not implemented and you only found out at runtime). that this is still a problem is very disappointing...
What is a CMake-built swift package to begin with? You're mixing build systems and expecting them to co-exist or what is the exact problem? I've done a lot of weird swift things so might be able to point you in the right direction.
E.g.: referencing a vcpkg-built package (without pkgconfig because not all packages have those files). Or telling SPM "Hey, I have this package which uses the cmake build system, and I want you to link to it and auto-generate module maps for it, and get the include directories from cmake". Things like that. So for me anyway it makes using swift painful. The same thing goes in reverse: using SPM packages from cmake (although this is more a cmake issue).
I'm sorry but what exactly are you doing? This is the first time I've ever heard any of this type of reasoning, and well, the fact that you're using AI makes me think you have no clue what you're actually talking about.
If its a reference cycle, instruments will find it. If it is a leak, instruments will find it. However, you seem to be worried about an implementation detail on how you get memory from your CPU which the mach kernel handles for you, and is something you don't quite grasp.
please don't reply with "I asked stupid generator", seriously, what is the actual issue you have?
App instalation isn't really even the problem. It is just the capabilities you have that you do not have access to. a modern iPad can easily run macOS as an 'app', if you will. The kernel is there, the userland is there, just not the checkbox from up high. Even Xcode works well in macOS VMs nowadays.
"work pc" -- random 50 dollar fire hazard running Linux. Anyway, those Android phones though they are obviously going to be the unreliable part in this story.
I don't know, you might be underestimating how much damage the orange in charge is really doing to the interests of the US. Change is slow, and the subtle things set in motion are always perceived too late. A simple example would be a small county in germany saving 5+ million a year thanks to moving away from microsoft. Add that to the budget of the many (largely european) opensource projects out there , and you can see things can shift, slowly, but rapidly once noticed.
