6 ms·

Swift Container Plugin

86 points by frizlab 1y ago

zombot 1y ago
Interesting! Does it run on macOS hosts only, or does it install any macOS inside the container?
- wojtek1942 1y ago
  Seems like it can run on standard container runtimes so you don't specifically need macOS and the container is Linux based. So there is no need to involve macOS at all since you can develop Swift programs on Linux for example.
tiffanyh 1y ago
What’s the general sentiment on Swift? It’s 11-years old and I don’t see it talked about much on HN (except for discussion on Apple libraries & bugs). Do people like it as a language, and why?
- happytoexplain 1y ago
  IMHO it's the best language I've used a significant amount, without a close second (where my sample size of extant languages is Swift, ObjC, Python, JS, TS, PHP, Java, Kotlin, C#, Haskell). It's the only language I've used where I have never asked "but why?". Every language feature and stdlib API just does what it says and acts in the way that makes the most sense. You're basically forced to handle every case (null, any type of error, switch cases, etc). It's highly dynamic, yet code tends to stay understandable. Apple is thoughtful about naming things and designing APIs. It's the only language I almost never need to write utility functions for - generally the type you're operating on has a method to do what you want, which you can easily discover with auto completion. Strings are sequences of graphemes, not code units or code points, and their API reflects this. It's not perfect, but nothing else comes as close. One of the most prominent complaints - compile time explosion - really only happens in contrived examples where you're using a bunch of literals in one expression, which isn't realistic. However, it's stuck in a single ecosystem. And let's not talk about some of the newer frameworks. Oh, and Xcode is a joke.
  - alain_gilbert 1y ago
    My two mains "why tf is this not built-in" are: "Why are tuple not Hashable ?!" Which means that you cannot have a tuple of Int `(1, 1)` as a key in a dict, and you have to make a struct that implement Hashable instead. And "Why do they not have a `.sum()` and I have to do `.reduce(0, +)` every time instead." Or implement it yourself extension Sequence where Element: AdditiveArithmetic { func sum() -> Element { reduce(.zero, +) } }
    - frizlab 1y ago
      I think tuples will be (soon-ish) Hashable but cannot as of now because they want to do it right and need something before they can do it.
    - zffr 1y ago
      Why do you feel the stdlib needs a .sum() if using .reduce() is so simple?
      - alain_gilbert 1y ago
        Because it's annoying to have to implement it every time you make a one off script (or small projects) among other things. And it is usually a pretty basic iterator standard to have it so that someone maybe not as familiar with concepts like reduce can just sum the sequence. Or if someone not familiar with reduce read your code, and is like "what is that `.reduce(0, +)` thing everywhere!?" while instead it should be a no brainer `.sum()` <-- "yup make sense" https://doc.rust-lang.org/std/iter/trait.Sum.html https://doc.rust-lang.org/std/iter/trait.Sum.html
  - sampullman 1y ago
    XCode (and other tooling) being a joke and compile issues make it tough for me to think of it as my favorite, but the language itself is definitely nice to work with. The compile time issues I have mainly come from TCA, but I still see them from time to time in normal code. I have a few other syntax gripes, but largely see it as competitive with Typescript and Rust in terms of how nice it is to use. TS and Rust blow it out of the water with tooling, though.
- jchw 1y ago
  I find it intriguing but have so far been unwilling to convince myself to give it a try on anything. It has a lot of good ideas, but I think Apple needs to relinquish more control over its future and direction for me to feel like a future plan change at Apple won't jeopardize its usefulness outside of Apple platforms. Presumably the reason why they want to keep it under their own organization is specifically so they can control their own destiny better, since Apple is heavily using Swift themselves; totally understandable, but trusting it for something that needs to be crossplatform in the long term seems potentially unwise. It's not fool-proof either. Microsoft started the .NET Foundation, but that hasn't stopped them from causing drama by pushing self-serving decisions from the top-down. I don't really fear the same sort of behavior from Apple very much, but I definitely worry that Apple might eventually lose interest on the cross platform part for sure. This is especially troubling because it is a fairly innovative language. If you get trapped on an unmaintained port of it, moving off of it seems like it might be hard. It's got a lot of clever ideas I haven't seen elsewhere.
  - pm 1y ago
    Swift evolution and governance is open and publicly documented. It will always be dominated by Apple engineers, but the evolution of the language is largely orthogonal to Apple's OS releases. I'm not sure how much of the standard library is available on the server side. However, I it's more about the engineers' interest than it is Apple's, and in that respect, the Swift ecosystem has been evolving constantly, e.g., the Swift toolchain was entirely divested from Xcode a month ago. I can't speak for the .NET ecosystem, but your fears are unfounded. Whether Swift is useful in a cross-platform context is another question, however.
    - jshier 1y ago
      Orthogonal? Odd thing to say given Swift's evolution and release timeline are entirely constrained by Apple's OS release schedule. We're currently going through the spike in evolution proposals by Apple engineers in preparation for the branching of Swift 6.2 next month before WWDC in June. As for server side, the standard library is entirely available on other platforms, with a subset available for embedded Swift. However, it's fairly limited when compared to something like Python, and cross platform support for the other libraries like swift-foundation or SwiftNIO is more limited (IIRC SwiftNIO still doesn't support Windows properly). I'm not sure what you're talking about with the tool chain. Apple has been producing toolchains that can run on macOS outside Xcode for years. Do you mean integration of swiftly? I think that just brought swiftly support to macOS for the first time. Ultimately I agree with jchw; Swift would be in a much better position if it wasn't controlled by Apple's process. Features could get more than a few months work at a time. We could have dedicated teams for maintenance intensive parts of the compiler, like the type checker or the diagnostics engine, rather than a single person, or a few people that switch between focus areas.
- heliophobicdude 1y ago
  It's a great language for Application-level software on a single platform (could be Linux). It has some challenges that it needs to solve to do great as a cross platform "general-purpose" programming language. It's paradoxically high level with its syntax and ergonomics but is tied down to the same cross platform headaches like in low level languages (e.g. cpp). Linking across cross platforms requires lots of careful thought and testing. Unlike cpp, it's not super portable. It requires a hefty 30 MB runtime for some features of the language to work. Try static executable hello world. That being said, it's possible. You can build cross platform applications with Swift, but you'd still have some of the same kinds of portability issues like in cpp but with nicer syntax and ergonomics.
- deze333 1y ago
  "Liking" is irrelevant to me. I do use it thoroughly though – I have written Linux containers (web apps) as well as native macOS and iOS apps. I am end-product creator and want my ideas to become end-user products and see the light of day. Delivery is everything. Swift offers convincing ease for writing abstractions that underpin the app layer. You can be as clever or as simple as you wish, it's up to you. I prefer to keep it simple. The other huge win for me is its ability to combine multiple language codebases at the SOURCE CODE LEVEL under a single project umbrella. Many of my projects use a mix of: - Swift - C++ - C The whole thing gets compiled from a bunch of source code folders with a single command. No wrappers or binary wrangling, simply call C++/C from Swift. Compile time is really fast for me with Swift 6 onwards. I use Xcode (and I am fine with it, it compiles really fast in year 2025) or VSCode (with Swift plugin) — both achieve the same thing in my experience. Want to build a Docker Linux container? Very simple too. I fine tune and debug the project on dev macOS machine then use a Docker Linux container to build it for Linux (on a Mac or Linux) and deploy the binary. It's a single binary file by default, all libs inside. Then copy it to my NAS or deploy to remote Linux server and enjoy the speed. Low friction, easy abstraction, fast delivery and binary machine code executable. That's what speaks to me.
- lenkite 1y ago
  Its popularity is steadily dropping over time since more and more people are moving to cross platform frameworks like Flutter.
- vbezhenar 1y ago
  Probably almost every developer working professionally on iOS uses Swift at this point. I, personally, don't like it and I prefer Objective C. But I'm not professional iOS developer, so take my words with grain of salt.
- frizlab 1y ago
  Personally I initially come from the « Apple world » but now I use Swift on the server and it’s a joy. By far my favorite language ever. I even wrote a tool to be able to run Swift scripts that have non-system dependencies![1] [1] https://github.com/xcode-actions/swift-sh https://github.com/xcode-actions/swift-sh PS: Yes, it’s a fork, but at the point I’m at there is nothing left from the original implementation. Even the way the program works is different.
- pjmlp 1y ago
  It is a great language for developers on Apple ecosystem, for portable code not so much. It stands with .NET on Windows, or Kotlin on Android, however outside Apple is at tooling level of .NET Core early days, think .NET Core 2.0. Mostly usable for Apple shops that need to deploy into Linux servers for their app backends, and share code.
- bsaul 1y ago
  Swift as a langage is fine, the problem is the ecosystem. It's been driven by apple for too long now, and suffers a lot from it. You would think that being constrained by one company would ensure the project remains lean, but apple actually had the opposite effect. Instead of focusing on real cross-platform support, or strong language foundations, they kept piling on features that nobody asked but made nice developer conference demos.
  - frizlab 1y ago
    That is probably the opposite of true. Go read the forums once in a while, the foundations are really well thought. I agree that function builders were probably added for the shiny SwiftUI (and was added too soon), as well as the property wrappers, but apart from that, the process of adding features in the language is actually quite transparent and well-defined. Also Swift now has real cross-platform support. All of the libraries I create I test on macOS, Linux, Windows, android and WASM/WASI.
    - bsaul 1y ago
      i tried building cross-platform libraries in swift for the past two years, with no success. I just did it in rust (ios / android / wasm) in a week, knowing nothing about the language. the swift wasm project still uses a forked compiler IIRC…
      - frizlab 1y ago
        > the swift wasm project still uses a forked compiler IIRC… No <https://forums.swift.org/t/stdlib-and-runtime-tests-for-wasm-wasi-now-available-on-swift-ci/70385 https://forums.swift.org/t/stdlib-and-runtime-tests-for-wasm...>. Like I told you, I cross compile to all of the targets directly on my Mac (except windows that I do technically on my Mac, but on a VM). I could use Linux all the same. Swift now has the concept of Swift SDK (`swift sdk install …`) and it is possible to target whatever (that has an SDK) easily. Yes, they took their sweet time, but it now works properly.
        1y ago
jchw 1y ago
This... is actually pretty great to have. Very cool. That said... It really just makes me bummed about the lack of good support for container and sandboxing technology on macOS. I know, totally different thing. But still, we'll probably never have a "native" Docker/Podman/etc. on macOS, and things like the Bazel or Nix sandbox are significantly less effective on macOS due to there just being less kernel APIs for isolating resources. e.g. There are no network namespaces. I get why, but it's surprising how limiting not having network namespaces is once you have used a platform that has an equivalent to this. For Nix it's really tricky since a lot of things need at least a working localhost inside the sandbox. I am sure increasing the surface area of XNU is not a serious consideration, for good reasons, but it's a bit of a shame.
- vbezhenar 1y ago
  There are Windows containers and I don't think that most developers using Docker on Windows are even aware of them. IMO it's kind of good to have Linux as a unified container platform. It's easy to run Linux application in Windows or macOS VM. It's hard form the licensing perspective to run Windows VM and it's very hard to run macOS VM.
  - pjmlp 1y ago
    We are very much aware, they are commonly used on deployments used in Windows Server. Typical examples, Sitecore, Sharepoint, Dynamics, Optimizelly, COM services, SQL Server.
  - jchw 1y ago
    I think it's just that Windows Containers are a lot unlike Linux Docker containers; they're not useless, but they're very different. I don't think Darwin containers have to be so different from Linux containers, not the least of which because Darwin is UNIX. It would be a lot more like if you ported Docker to run natively on BSD than Windows, since it basically is that. An easy solution to the licensing issue is just having an open source userland that you can use, which Darwin sorta does. That said, since XNU syscalls are not stable, there is some awkwardness here. Either they would need to be made stable somehow (e.g. by providing something like personalities, where different processes get different syscall behavior) or the runtime would need to drop libc/base libraries in from the sky and containers would just need to assume they're available at a specific location. Either thing seems quite viable if Apple wanted to do it, IMO.
fnord77 1y ago
> Container images are the standard way to package cloud software today. Shame there's no macos native container system or way to make one (my understanding is the kernel isolation primitives are not there)
- frizlab 1y ago
  Yes. I speculate they are actually working on this internally but I have no proof (they must have thought about it!). All the advances in the virtualization they are currently doing makes me think they will eventually release a built in container technology.
  - fnord77 1y ago
    I'm not so sure. Containers don't need a hypervisor, they're just processes. They seem to be going in a different direction.
- PaulRobinson 1y ago
  It has to be coming. Plenty of work done on virtualization, and you can see the VR and GenAI roadmaps playing out to the point where they want devs building for the Apple ecosystem to be able to run stuff securely in cloud, which means they will want a cloud offering to compete, which means they'll want their own container runtime with macOS APIs but in Apple's DCs. This is an interesting first step though - it means devs who now want to build something that talks to cloud functionality in AWS or GCP have the option to stay in a single language. If it gets traction, you can imagine they'll accelerate investment.
antfarm 1y ago
I love Swift, but it has the only compiler that ever told me to rewrite my code because it cannot analyze it in a reasonable length of time.
- bsaul 1y ago
  anecdotally, it was also the first production compiler that i saw crash, and it was on regular code.
  - cvwright 1y ago
    And Swift compiler crashes aren’t even rare. You get used to it and learn how to track down the code that caused it. I think I’ve seen a C compiler crash once or maybe twice, ever.
    - bsaul 1y ago
      The fact that a compiler is crashing really makes me shiver. If the compiler is crashing because of unexpected combinations, then what about the generated code ?
      - frizlab 1y ago
        There were also issues in the generated code, yeah. But to be fair that front has been hugely enhanced; it’s been a very long while since I’ve since the Swift compiler crash (and I do weird stuff too).
- zapnuk 1y ago
  It's a contender for a "best idea and worst execution" award for programming languages in the last 20 years. I'd like to think that if things went just a little bit better it would have beed the ideal programming language for anything cloud / backend related.
  - bsaul 1y ago
    The swift language is absolutely fantastic. But the constraints (such as objective-c compatibility) made it a juggernaut. It's actually very surprising they managed to get that language work at all given the size of it. In that regard, i wouldn't say execution was bad. It was just unrealistic, and too much was asked from it.
finnjohnsen2 1y ago
I dont love the idea of Apple eco system for server side development. I trust them to try make a great eco system for their own OSes based on their self interrest. I do not trust them to drive and maintain a server side eco system, because I don’t see how the effort is directly linked to making money. That said, Swift and SwiftUI is super nice, so I know they know how to make great software for their OS-es. Almost. Once they fix XCode.
- AceJohnny2 1y ago
  > I dont love the idea of Apple eco system for server side development. 100%! Everyone repeat after me: "macOS Is Not A Server OS" macOS is approximately the worst OS you can run a server on: 1. It is buggy. We had a bug in Sonoma where our CI machines would freeze on some filesystem access. The bug was fixed during Sonoma's lifetime... but only released in Sequoia. Before that we had a rare bug that plagued us for years (once every few months across several CI machines) where a process would fail to execute with "/bin/sh: cannot execute binary file", indicating an erroneous ENOEXEC from the kernel (that bug quietly disappeared) 2. It has no LTS version. See above filesystem hang. Want a fix? Cool, it comes only in the next major OS version, along with a host other changes you didn't want, and new bugs! (see point 4 below) 3. It is just poorly documented. Apple's doc are awful, poorly searcheable, they will change things and not document it, you're left with the community trying to reverse-engineer everything (I cannot recommend eclecticlight.co enough!) 4. It's just bloated with cruft for consumers. Upgrade to Sequoia 15.3? You got a free download of "Apple Intelligence" models, there go a few GBs! Again rely on the community to come up with the magic settings to disable stuff. Ask me how I feel about macOS as a server. (I lament the death of XServe, which could've driven more server-focused software quality)
  - frizlab 1y ago
    > macOS Is Not A Server OS It does not matter, Swift server-side can run (and be built) on Linux (or Windows BTW, or even embedded platforms (a subset of the language anyway))…
- robertjpayne 1y ago
deze333 1y ago
What is Swift? Why Swift? A lot of discussion here touched this topic. My experience here after 10 years with Swift, starting from version 1. This is how I understood the language through the process of creating several apps (and web services) of non-trivial complexity. Swift helps those who want to build end-user products. Swift is the language for those who need to deliver end-user products, deliver fast and iterate often with minimal friction. You got to be a practical creator who needs to create and deploy to market fast. It's all about achievability of end result within modern world's time constraints. This is where it shines. Swift may not fit more pure paradigms. If you're after the pure art of programming then other languages may speak to you better. In other words, Swift is extremely PRACTICAL – meaning create, deploy and earn living – and is squarely focused on people who need that. Naturally, not everybody will resonate with its core mission statement.
- wslh 1y ago
  As a casual Swift desktop developer, I also wonder about how practical and fast Swift is, especially when compared to scripting languages like Python. For instance, last week, I was working on bit manipulation and realized that Swift has methods to count 1 and 0 bits: let value: UInt8 = 0b11010101 let count = value.nonzeroBitCount
  - deze333 1y ago
    It's fast enough to make running an app feel like running a native app – faster start time, less memory used, less power hungry, more responsive UI – compared to browser based cross-platform apps. One can say it achieves maximum user interaction speed. For most critical calculations, one can easily integrate C++/C libraries – at the source code level – which Swift can compile, link and call directly. Or drop down to unsafe features of Swift and achieve speeds comparable to C++. But that's not really needed in most of real life use cases. Convenience is what really matters when it comes to Swift.
    - msk-lywenn 1y ago
      "feel like running a native app"? Swift apps are native apps, AFAIK
singularity2001 1y ago
registry.example.com/myservice ? You lost me there. swift package --swift-sdk x86_64-swift-linux-musl build-container-image --repository registry.example.com/myservice No idea how to use it.
- mac9 1y ago
  [dead]
- frizlab 1y ago
  You have to create your own docker-like registry, or use a public one.

86 points by frizlab 1y ago

zombot 1y ago

Interesting! Does it run on macOS hosts only, or does it install any macOS inside the container?

wojtek1942 1y ago
Seems like it can run on standard container runtimes so you don't specifically need macOS and the container is Linux based. So there is no need to involve macOS at all since you can develop Swift programs on Linux for example.

tiffanyh 1y ago

What’s the general sentiment on Swift? It’s 11-years old and I don’t see it talked about much on HN (except for discussion on Apple libraries & bugs). Do people like it as a language, and why?

happytoexplain 1y ago
IMHO it's the best language I've used a significant amount, without a close second (where my sample size of extant languages is Swift, ObjC, Python, JS, TS, PHP, Java, Kotlin, C#, Haskell). It's the only language I've used where I have never asked "but why?". Every language feature and stdlib API just does what it says and acts in the way that makes the most sense. You're basically forced to handle every case (null, any type of error, switch cases, etc). It's highly dynamic, yet code tends to stay understandable. Apple is thoughtful about naming things and designing APIs. It's the only language I almost never need to write utility functions for - generally the type you're operating on has a method to do what you want, which you can easily discover with auto completion. Strings are sequences of graphemes, not code units or code points, and their API reflects this. It's not perfect, but nothing else comes as close. One of the most prominent complaints - compile time explosion - really only happens in contrived examples where you're using a bunch of literals in one expression, which isn't realistic. However, it's stuck in a single ecosystem. And let's not talk about some of the newer frameworks. Oh, and Xcode is a joke.
- alain_gilbert 1y ago
  My two mains "why tf is this not built-in" are: "Why are tuple not Hashable ?!" Which means that you cannot have a tuple of Int `(1, 1)` as a key in a dict, and you have to make a struct that implement Hashable instead. And "Why do they not have a `.sum()` and I have to do `.reduce(0, +)` every time instead." Or implement it yourself extension Sequence where Element: AdditiveArithmetic { func sum() -> Element { reduce(.zero, +) } }
  - frizlab 1y ago
    I think tuples will be (soon-ish) Hashable but cannot as of now because they want to do it right and need something before they can do it.
  - zffr 1y ago
    Why do you feel the stdlib needs a .sum() if using .reduce() is so simple?
    - alain_gilbert 1y ago
      Because it's annoying to have to implement it every time you make a one off script (or small projects) among other things. And it is usually a pretty basic iterator standard to have it so that someone maybe not as familiar with concepts like reduce can just sum the sequence. Or if someone not familiar with reduce read your code, and is like "what is that `.reduce(0, +)` thing everywhere!?" while instead it should be a no brainer `.sum()` <-- "yup make sense" https://doc.rust-lang.org/std/iter/trait.Sum.html https://doc.rust-lang.org/std/iter/trait.Sum.html
- sampullman 1y ago
  XCode (and other tooling) being a joke and compile issues make it tough for me to think of it as my favorite, but the language itself is definitely nice to work with. The compile time issues I have mainly come from TCA, but I still see them from time to time in normal code. I have a few other syntax gripes, but largely see it as competitive with Typescript and Rust in terms of how nice it is to use. TS and Rust blow it out of the water with tooling, though.
jchw 1y ago
I find it intriguing but have so far been unwilling to convince myself to give it a try on anything. It has a lot of good ideas, but I think Apple needs to relinquish more control over its future and direction for me to feel like a future plan change at Apple won't jeopardize its usefulness outside of Apple platforms. Presumably the reason why they want to keep it under their own organization is specifically so they can control their own destiny better, since Apple is heavily using Swift themselves; totally understandable, but trusting it for something that needs to be crossplatform in the long term seems potentially unwise. It's not fool-proof either. Microsoft started the .NET Foundation, but that hasn't stopped them from causing drama by pushing self-serving decisions from the top-down. I don't really fear the same sort of behavior from Apple very much, but I definitely worry that Apple might eventually lose interest on the cross platform part for sure. This is especially troubling because it is a fairly innovative language. If you get trapped on an unmaintained port of it, moving off of it seems like it might be hard. It's got a lot of clever ideas I haven't seen elsewhere.
- pm 1y ago
  Swift evolution and governance is open and publicly documented. It will always be dominated by Apple engineers, but the evolution of the language is largely orthogonal to Apple's OS releases. I'm not sure how much of the standard library is available on the server side. However, I it's more about the engineers' interest than it is Apple's, and in that respect, the Swift ecosystem has been evolving constantly, e.g., the Swift toolchain was entirely divested from Xcode a month ago. I can't speak for the .NET ecosystem, but your fears are unfounded. Whether Swift is useful in a cross-platform context is another question, however.
  - jshier 1y ago
    Orthogonal? Odd thing to say given Swift's evolution and release timeline are entirely constrained by Apple's OS release schedule. We're currently going through the spike in evolution proposals by Apple engineers in preparation for the branching of Swift 6.2 next month before WWDC in June. As for server side, the standard library is entirely available on other platforms, with a subset available for embedded Swift. However, it's fairly limited when compared to something like Python, and cross platform support for the other libraries like swift-foundation or SwiftNIO is more limited (IIRC SwiftNIO still doesn't support Windows properly). I'm not sure what you're talking about with the tool chain. Apple has been producing toolchains that can run on macOS outside Xcode for years. Do you mean integration of swiftly? I think that just brought swiftly support to macOS for the first time. Ultimately I agree with jchw; Swift would be in a much better position if it wasn't controlled by Apple's process. Features could get more than a few months work at a time. We could have dedicated teams for maintenance intensive parts of the compiler, like the type checker or the diagnostics engine, rather than a single person, or a few people that switch between focus areas.
heliophobicdude 1y ago
It's a great language for Application-level software on a single platform (could be Linux). It has some challenges that it needs to solve to do great as a cross platform "general-purpose" programming language. It's paradoxically high level with its syntax and ergonomics but is tied down to the same cross platform headaches like in low level languages (e.g. cpp). Linking across cross platforms requires lots of careful thought and testing. Unlike cpp, it's not super portable. It requires a hefty 30 MB runtime for some features of the language to work. Try static executable hello world. That being said, it's possible. You can build cross platform applications with Swift, but you'd still have some of the same kinds of portability issues like in cpp but with nicer syntax and ergonomics.
deze333 1y ago
"Liking" is irrelevant to me. I do use it thoroughly though – I have written Linux containers (web apps) as well as native macOS and iOS apps. I am end-product creator and want my ideas to become end-user products and see the light of day. Delivery is everything. Swift offers convincing ease for writing abstractions that underpin the app layer. You can be as clever or as simple as you wish, it's up to you. I prefer to keep it simple. The other huge win for me is its ability to combine multiple language codebases at the SOURCE CODE LEVEL under a single project umbrella. Many of my projects use a mix of: - Swift - C++ - C The whole thing gets compiled from a bunch of source code folders with a single command. No wrappers or binary wrangling, simply call C++/C from Swift. Compile time is really fast for me with Swift 6 onwards. I use Xcode (and I am fine with it, it compiles really fast in year 2025) or VSCode (with Swift plugin) — both achieve the same thing in my experience. Want to build a Docker Linux container? Very simple too. I fine tune and debug the project on dev macOS machine then use a Docker Linux container to build it for Linux (on a Mac or Linux) and deploy the binary. It's a single binary file by default, all libs inside. Then copy it to my NAS or deploy to remote Linux server and enjoy the speed. Low friction, easy abstraction, fast delivery and binary machine code executable. That's what speaks to me.
lenkite 1y ago
Its popularity is steadily dropping over time since more and more people are moving to cross platform frameworks like Flutter.
vbezhenar 1y ago
Probably almost every developer working professionally on iOS uses Swift at this point. I, personally, don't like it and I prefer Objective C. But I'm not professional iOS developer, so take my words with grain of salt.
frizlab 1y ago
Personally I initially come from the « Apple world » but now I use Swift on the server and it’s a joy. By far my favorite language ever. I even wrote a tool to be able to run Swift scripts that have non-system dependencies![1] [1] https://github.com/xcode-actions/swift-sh https://github.com/xcode-actions/swift-sh PS: Yes, it’s a fork, but at the point I’m at there is nothing left from the original implementation. Even the way the program works is different.
pjmlp 1y ago
It is a great language for developers on Apple ecosystem, for portable code not so much. It stands with .NET on Windows, or Kotlin on Android, however outside Apple is at tooling level of .NET Core early days, think .NET Core 2.0. Mostly usable for Apple shops that need to deploy into Linux servers for their app backends, and share code.
bsaul 1y ago
Swift as a langage is fine, the problem is the ecosystem. It's been driven by apple for too long now, and suffers a lot from it. You would think that being constrained by one company would ensure the project remains lean, but apple actually had the opposite effect. Instead of focusing on real cross-platform support, or strong language foundations, they kept piling on features that nobody asked but made nice developer conference demos.
- frizlab 1y ago
  That is probably the opposite of true. Go read the forums once in a while, the foundations are really well thought. I agree that function builders were probably added for the shiny SwiftUI (and was added too soon), as well as the property wrappers, but apart from that, the process of adding features in the language is actually quite transparent and well-defined. Also Swift now has real cross-platform support. All of the libraries I create I test on macOS, Linux, Windows, android and WASM/WASI.
  - bsaul 1y ago
    i tried building cross-platform libraries in swift for the past two years, with no success. I just did it in rust (ios / android / wasm) in a week, knowing nothing about the language. the swift wasm project still uses a forked compiler IIRC…
    - frizlab 1y ago
      > the swift wasm project still uses a forked compiler IIRC… No <https://forums.swift.org/t/stdlib-and-runtime-tests-for-wasm-wasi-now-available-on-swift-ci/70385 https://forums.swift.org/t/stdlib-and-runtime-tests-for-wasm...>. Like I told you, I cross compile to all of the targets directly on my Mac (except windows that I do technically on my Mac, but on a VM). I could use Linux all the same. Swift now has the concept of Swift SDK (`swift sdk install …`) and it is possible to target whatever (that has an SDK) easily. Yes, they took their sweet time, but it now works properly.
      - 1y ago

jchw 1y ago

This... is actually pretty great to have. Very cool. That said... It really just makes me bummed about the lack of good support for container and sandboxing technology on macOS. I know, totally different thing. But still, we'll probably never have a "native" Docker/Podman/etc. on macOS, and things like the Bazel or Nix sandbox are significantly less effective on macOS due to there just being less kernel APIs for isolating resources. e.g. There are no network namespaces. I get why, but it's surprising how limiting not having network namespaces is once you have used a platform that has an equivalent to this. For Nix it's really tricky since a lot of things need at least a working localhost inside the sandbox. I am sure increasing the surface area of XNU is not a serious consideration, for good reasons, but it's a bit of a shame.

vbezhenar 1y ago
There are Windows containers and I don't think that most developers using Docker on Windows are even aware of them. IMO it's kind of good to have Linux as a unified container platform. It's easy to run Linux application in Windows or macOS VM. It's hard form the licensing perspective to run Windows VM and it's very hard to run macOS VM.
- pjmlp 1y ago
  We are very much aware, they are commonly used on deployments used in Windows Server. Typical examples, Sitecore, Sharepoint, Dynamics, Optimizelly, COM services, SQL Server.
- jchw 1y ago
  I think it's just that Windows Containers are a lot unlike Linux Docker containers; they're not useless, but they're very different. I don't think Darwin containers have to be so different from Linux containers, not the least of which because Darwin is UNIX. It would be a lot more like if you ported Docker to run natively on BSD than Windows, since it basically is that. An easy solution to the licensing issue is just having an open source userland that you can use, which Darwin sorta does. That said, since XNU syscalls are not stable, there is some awkwardness here. Either they would need to be made stable somehow (e.g. by providing something like personalities, where different processes get different syscall behavior) or the runtime would need to drop libc/base libraries in from the sky and containers would just need to assume they're available at a specific location. Either thing seems quite viable if Apple wanted to do it, IMO.

fnord77 1y ago

> Container images are the standard way to package cloud software today. Shame there's no macos native container system or way to make one (my understanding is the kernel isolation primitives are not there)

frizlab 1y ago
Yes. I speculate they are actually working on this internally but I have no proof (they must have thought about it!). All the advances in the virtualization they are currently doing makes me think they will eventually release a built in container technology.
- fnord77 1y ago
  I'm not so sure. Containers don't need a hypervisor, they're just processes. They seem to be going in a different direction.
PaulRobinson 1y ago
It has to be coming. Plenty of work done on virtualization, and you can see the VR and GenAI roadmaps playing out to the point where they want devs building for the Apple ecosystem to be able to run stuff securely in cloud, which means they will want a cloud offering to compete, which means they'll want their own container runtime with macOS APIs but in Apple's DCs. This is an interesting first step though - it means devs who now want to build something that talks to cloud functionality in AWS or GCP have the option to stay in a single language. If it gets traction, you can imagine they'll accelerate investment.

antfarm 1y ago

I love Swift, but it has the only compiler that ever told me to rewrite my code because it cannot analyze it in a reasonable length of time.

bsaul 1y ago
anecdotally, it was also the first production compiler that i saw crash, and it was on regular code.
- cvwright 1y ago
  And Swift compiler crashes aren’t even rare. You get used to it and learn how to track down the code that caused it. I think I’ve seen a C compiler crash once or maybe twice, ever.
  - bsaul 1y ago
    The fact that a compiler is crashing really makes me shiver. If the compiler is crashing because of unexpected combinations, then what about the generated code ?
    - frizlab 1y ago
      There were also issues in the generated code, yeah. But to be fair that front has been hugely enhanced; it’s been a very long while since I’ve since the Swift compiler crash (and I do weird stuff too).
zapnuk 1y ago
It's a contender for a "best idea and worst execution" award for programming languages in the last 20 years. I'd like to think that if things went just a little bit better it would have beed the ideal programming language for anything cloud / backend related.
- bsaul 1y ago
  The swift language is absolutely fantastic. But the constraints (such as objective-c compatibility) made it a juggernaut. It's actually very surprising they managed to get that language work at all given the size of it. In that regard, i wouldn't say execution was bad. It was just unrealistic, and too much was asked from it.

finnjohnsen2 1y ago

I dont love the idea of Apple eco system for server side development. I trust them to try make a great eco system for their own OSes based on their self interrest. I do not trust them to drive and maintain a server side eco system, because I don’t see how the effort is directly linked to making money. That said, Swift and SwiftUI is super nice, so I know they know how to make great software for their OS-es. Almost. Once they fix XCode.

AceJohnny2 1y ago
> I dont love the idea of Apple eco system for server side development. 100%! Everyone repeat after me: "macOS Is Not A Server OS" macOS is approximately the worst OS you can run a server on: 1. It is buggy. We had a bug in Sonoma where our CI machines would freeze on some filesystem access. The bug was fixed during Sonoma's lifetime... but only released in Sequoia. Before that we had a rare bug that plagued us for years (once every few months across several CI machines) where a process would fail to execute with "/bin/sh: cannot execute binary file", indicating an erroneous ENOEXEC from the kernel (that bug quietly disappeared) 2. It has no LTS version. See above filesystem hang. Want a fix? Cool, it comes only in the next major OS version, along with a host other changes you didn't want, and new bugs! (see point 4 below) 3. It is just poorly documented. Apple's doc are awful, poorly searcheable, they will change things and not document it, you're left with the community trying to reverse-engineer everything (I cannot recommend eclecticlight.co enough!) 4. It's just bloated with cruft for consumers. Upgrade to Sequoia 15.3? You got a free download of "Apple Intelligence" models, there go a few GBs! Again rely on the community to come up with the magic settings to disable stuff. Ask me how I feel about macOS as a server. (I lament the death of XServe, which could've driven more server-focused software quality)
- frizlab 1y ago
  > macOS Is Not A Server OS It does not matter, Swift server-side can run (and be built) on Linux (or Windows BTW, or even embedded platforms (a subset of the language anyway))…
robertjpayne 1y ago

deze333 1y ago

What is Swift? Why Swift? A lot of discussion here touched this topic. My experience here after 10 years with Swift, starting from version 1. This is how I understood the language through the process of creating several apps (and web services) of non-trivial complexity. Swift helps those who want to build end-user products. Swift is the language for those who need to deliver end-user products, deliver fast and iterate often with minimal friction. You got to be a practical creator who needs to create and deploy to market fast. It's all about achievability of end result within modern world's time constraints. This is where it shines. Swift may not fit more pure paradigms. If you're after the pure art of programming then other languages may speak to you better. In other words, Swift is extremely PRACTICAL – meaning create, deploy and earn living – and is squarely focused on people who need that. Naturally, not everybody will resonate with its core mission statement.

wslh 1y ago
As a casual Swift desktop developer, I also wonder about how practical and fast Swift is, especially when compared to scripting languages like Python. For instance, last week, I was working on bit manipulation and realized that Swift has methods to count 1 and 0 bits: let value: UInt8 = 0b11010101 let count = value.nonzeroBitCount
- deze333 1y ago
  It's fast enough to make running an app feel like running a native app – faster start time, less memory used, less power hungry, more responsive UI – compared to browser based cross-platform apps. One can say it achieves maximum user interaction speed. For most critical calculations, one can easily integrate C++/C libraries – at the source code level – which Swift can compile, link and call directly. Or drop down to unsafe features of Swift and achieve speeds comparable to C++. But that's not really needed in most of real life use cases. Convenience is what really matters when it comes to Swift.
  - msk-lywenn 1y ago
    "feel like running a native app"? Swift apps are native apps, AFAIK

singularity2001 1y ago

registry.example.com/myservice ? You lost me there. swift package --swift-sdk x86_64-swift-linux-musl build-container-image --repository registry.example.com/myservice No idea how to use it.

mac9 1y ago
[dead]
frizlab 1y ago
You have to create your own docker-like registry, or use a public one.