7 ms·

Swift on FreeBSD Preview

235 points by glhaynes 11mo ago

hazn 11mo ago
what i am pondering is: is it easier in theory to port swift to freebsd rather than linux? the facts that macOs has shared history with freebsd tells me yes, the fact that llvm favors linux (?) tells me both. also, congrats, the swift and freebsd are ambitious in terms of new deployment platforms and compatibility! (see embedded swift, oci freebsd containers, freebsd on firecracker)
- rootnod3 11mo ago
  Why would llvm favor linux? FreeBSD also officially moved from GCC to LLVM for the base system, so I don't see why LLVM wouldn't support it.
  - rjsw 11mo ago
    I would say that LLVM is more important to FreeBSD than it is to Linux.
  - hazn 11mo ago
    a good question, my line of thinking was: if llvm allows easy ports to freebsd, why is freebsd always a lower tier than linux in llvm based projects? weak reasoning, as it might just be a supply/demand and not a product quality question
    - Klonoar 11mo ago
      > Why… It’s almost always available resources.
      - MBCook 11mo ago
        Possibly demand as well. We know that Apple operates a whole bunch of Linux servers, do we know if they’re running FreeBSD internally?
- zapzupnz 11mo ago
  > is it easier in theory to port swift to freebsd rather than linux? the facts that macOs has shared history with freebsd tells me yes That shared history goes back a LONG way. The base components from FreeBSD that are in macOS are absolutely ancient. I think the most modern shared components are just the userland tools. So I don't think it would make much difference at all.
- Someone 11mo ago
  I don’t know whether you know, but there has been a Linux port for quite a while (https://www.swift.org/blog/swift-linux-port/ https://www.swift.org/blog/swift-linux-port/ is from December 2015). https://www.swift.org/install/linux/ https://www.swift.org/install/linux/ points to https://hub.docker.com/_/swift https://hub.docker.com/_/swift, which has images for Red Hat, Amazon Linux, maybe others.
jiehong 11mo ago
Porting on more platforms is always great, and a good way to find hidden assumptions.
rootnod3 11mo ago
Are they also gonna take the reigns and officially be the maintainer of the FreeBSD package in ports or are they gonna wait for some volunteer to package it for them and choke on the bug reports whenever someone finds an issue?
vtail 11mo ago
Do people use Swift outside of Apple iOS/macOS development in real life? Especially on platforms like Windows/Linux/*BSD?
- rootnod3 11mo ago
  I guess so. In a way it makes sense if you can share your code base between the iOS/MacOS app and your backend. It makes development easier. But I guess that the majority of apps is not running MacOS servers for the backend. So far it's probably some node backends and all going JSON inbetween. But for some dedicated apps without a web portal inbetween it might be easier if app and backend are both in Swift.
- repelsteeltje 11mo ago
  Only for iOS apps. Apple does not offer a backend.
  - turnsout 11mo ago
    Not true at all. Swift is a very capable backend language, Apple has open sourced a lot of great libraries to power server software development, and there are projects like Vapor [0] that are used in production. [0]: https://vapor.codes https://vapor.codes
    - repelsteeltje 11mo ago
      Ah. You're right, I phrased that ambiguously, sorry. I meant to point out that there is no apple native cloud solution where you can run swift on apple hardware. So if your iOS app needs to talk to a backend that you want to develop and host, you need to run that backend on an OS with cloud support, like Linux, some other Unix or windows. But not macOS or some other "Apple cloud" hosting. For reasons stated above, you might in that case choose Swift.
      - turnsout 11mo ago
        Ah, gotcha—yes, that is actually a pain point and a strange omission. If you need to run backend code for any reason to support your app, Apple literally offers nothing. IBM at one point offered Swift "serverless" lambdas/cloud functions, which made me briefly hopeful that Apple could do the same, but that service was deprecated years ago, and Apple has shown no motion there.
latexr 11mo ago
> The Swift compiler and runtimes have a few dependencies. Please install the following dependencies: > (…) python3 (…) Wait, which part requires Python, and why? And is that only for FreeBSD, or in general? And is that something which will change? Feels very weird that a compiled systems language is dependent on a high-level scripting language.
- TheJoeMan 11mo ago
  https://github.com/orgs/swiftlang/repositories?q=lang%3Apython&type=all https://github.com/orgs/swiftlang/repositories?q=lang%3Apyth... From a quick look, appears to be the test suite. Which makes sense, hard to validate your language with itself.
  - ux266478 11mo ago
    That greatly depends on the codebase and the language. https://github.com/SWI-Prolog/swipl-devel/blob/master/tests/test.pl https://github.com/SWI-Prolog/swipl-devel/blob/master/tests/...
- jshier 11mo ago
  LLDB also needs python if you want to use its scripting integration.
- bananapub 11mo ago
  it's not weird at all - you need something sensible to run complicated things while bootstrapping the compiler. Rust does the same thing: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html https://rustc-dev-guide.rust-lang.org/building/how-to-build-...
- mshockwave 11mo ago
  It's likely that Swift compiler is using LLVM LIT (https://llvm.org/docs/CommandGuide/lit.html https://llvm.org/docs/CommandGuide/lit.html), which is implemented in python, as the test driver
  - 11mo ago
hirvi74 11mo ago
I absolutely love Swift. I understand some may disagree, and perhaps many of their arguments are quite valid. However, no language is perfect, and I just feel like Swift has some features that shows that a lot of thought was put into some features -- not to disrespect any other languages. Considering the static typing, guard statements, protocols, lack of ++/-- operators (Lattner's argument was convincing), let/var, being able to make function parameters immutable, being able to lock symbols down to the file level, easy integration with c languages, etc.. I have not used SwiftUI, so I cannot judge it, but I do not think any issues with it are compelling arguments against Swift as a language (that I have read). Lattner is my modern-age programming-hero. I'm glad to see FreeBSD will be able to share the love soon enough.
- ezfe 11mo ago
  And SwiftUI is not part of Swift open source, it's just for Apple platforms. The underlying Swift language features could be used by other UI systems if someone wanted to make a crossplatform system, though.
- myko 11mo ago
  Swift is such an excellent language. I hope it continues to grow outside of the Apple ecosystem.
- troupo 11mo ago
  You can watch Lattner's interview with Theprimeagen. It's a haphazardly designed language where pressure to ship from Apple as a whole overrides any design or development considerations. That's why you end up with a compiler that barfs at even the simplest SwiftUI code because Swift's type system is overly complicated and undecidable. And makes the compiler dog slow. That's why you end up with 200+ keywords [1] with more added each release. That's how you end up with idiocy like `guard let self = self else { return }` (I think they "fixed" this with some syntax sugar) because making if statements understand nulls is beyond the capabilities of heroes apparently. And this is just surface level that immediately came to mind. [1] It's not a typo: https://x.com/jacobtechtavern/status/1841251621004538183 https://x.com/jacobtechtavern/status/1841251621004538183
turnsout 11mo ago
Wow, this is great news. I still don't understand why it has taken so long, when Swift on Linux has been around for 10 years. But as a FreeBSD user, this is very welcome!
fridder 11mo ago
Loving all the new developments with FreeBSD.
kchoudhu 11mo ago
I'm not complaining, but also why?
- zapzupnz 11mo ago
  Why not? Why wouldn't an open source project want their increasingly platform-agnostic language to be supported on as many platforms as possible?
- MBCook 11mo ago
  It’s a fantastic language? I’ve come to really like it. Strong type system, is it to work with, lots of resources available, compiles to a binary, interfacing with any other language that you can link to with C, the syntax doesn’t look ugly to me (quite subjective), excellent concurrency support… What can I say I’m a fan.
gocsjess 11mo ago
I believe apple is making OCI-compliant containers which is written in swift. I hope this helps the containerization in FreeBSD.
- bartekrutkowski 11mo ago
  In what sense? FreeBSD had containers before anyone heard about Docker ;)
  - righthand 11mo ago
    Yeah talk about reinventing the wheel so Linux people don’t have to learn a slightly different system (one that is ironically easier to use and better organized than Oci containers).
  - Gud 11mo ago
    Jails are not containers.
    - yjftsjthsd-h 11mo ago
      By what definition would LXC be containers and jails not be?
  - irusensei 11mo ago
    Jails are great but are not OCI-compliant.
    - jen20 11mo ago
      So? They predate a standard which was basically extracted from Docker.
      - pstuart 11mo ago
        I think the OCI factor being noted here is the packaging not the containerized runtime.
DeathArrow 11mo ago
What can you build with Swift on FreeBSD which isn't easier with other languages?
- jhatemyjob 11mo ago
  Software that is meant to run on Apple platforms.
  - frizlab 11mo ago
    absolutely not
  - zapzupnz 11mo ago
    Swift on Apple and Swift on literally-everything-else are very different stories at the moment.
    - frizlab 11mo ago
      Not that different anymore, except Apple-proprietary frameworks (e.g. SwiftUI) are not available outside of Apple platforms.
      - zapzupnz 11mo ago
        This isn't to dispute your assertion, but I think things are still quite a bit different. A lot of things provided by Foundation on macOS are still not available in Linux's Foundation, nor CoreFoundation, so one has to defer to something like Glibc — which, then again, is not available to the static Linux distro. On Windows, it's useful to use WinSDK to do things that Foundation would normally do. There's all sorts of little things that Swift on non-Apple platforms just don't have yet. Little footguns because the Swift rewrite of Foundation isn't quite equivalent yet.
        frizlab 11mo ago
        It is getting close though, which was my point. Honestly I got bit recently by DateComponentFormatter that does not exists on Linux, but it’s been a while since I’ve had things like that. We even have (NS)AttributedStrings (including the NS version, which I did not expect…). Of course no fonts and co, but that’s AppKit/UIKit/SwiftUI, so it’s normal.
oaiey 11mo ago
A lot of good news recently for swift. I am a bit jealous as my go to language C# / .NET is recently not announcing fancy things. I really like swift going beyond Apple. Particularly the port to android is IMHO crucial, however, now they are in the UI cross platform hell. Let us see if Apple is playing this better than Microsoft. Unfortunately, I have little hope. The only native contenders in the field right now are IMHO are react native and flutter which are both UI toolkits first and language second. Which I find gruesome.
- troupo 11mo ago
  > I am a bit jealous as my go to language C# / .NET is recently not announcing fancy things. Depends on what you think fancy things are. Both C# and .net are busy releasing a lot of features. You're forgetting that C# is a 25-year-old language at this time. The exciting features they release are things like "access native memory allocation in a GC language", "native Arm64 support", "support for post-quantum cryptography", "tensor support" etc. while already running on all the platforms that Swift is only now announcing as achievements.
  - SvenL 11mo ago
    Yeah, also the ecosystem, aspire, ef core, Orleans, ML.NET etc..at this point I don't know what's really missing.
- cosmic_cheese 11mo ago
  It'd be nice if Apple made SwiftUI cross platform and I'd be singing in the streets if UIKit got ported, but that seems unlikely at best. I believe that there's strong community interest in some kind of Swift UI framework for Android, though, and so there's a substantial chance that a third party solution will appear.
  - CharlesW 11mo ago
    skip.tools is one third-party solution for creating Swift + SwiftUI apps for Android today.
ethin 11mo ago
Swift just needs to gain cmake bidirectional support, like, SPM should be able to compile CMake projects and vice-versa, or be able to use vcpkg. Once that's done, I could very much see myself switching to it for a lot of things.
- wahnfrieden 11mo ago
  SPM support for CMake is in progress
  - ethin 11mo ago
    I know, and that's a good thing. That's probably one of the biggest blockers for it's wider adoption. I hope that CMake can eventually get similar abilities for calling into SPM or just outright handling Swift package manifests. That might be too much to ask though.
lukeh 11mo ago
I did try to build a medium sized project with this today. Still a lot of dependencies that will need to be updated for the differences between glibc and libc.

235 points by glhaynes 11mo ago

hazn 11mo ago

what i am pondering is: is it easier in theory to port swift to freebsd rather than linux? the facts that macOs has shared history with freebsd tells me yes, the fact that llvm favors linux (?) tells me both. also, congrats, the swift and freebsd are ambitious in terms of new deployment platforms and compatibility! (see embedded swift, oci freebsd containers, freebsd on firecracker)

rootnod3 11mo ago
Why would llvm favor linux? FreeBSD also officially moved from GCC to LLVM for the base system, so I don't see why LLVM wouldn't support it.
- rjsw 11mo ago
  I would say that LLVM is more important to FreeBSD than it is to Linux.
- hazn 11mo ago
  a good question, my line of thinking was: if llvm allows easy ports to freebsd, why is freebsd always a lower tier than linux in llvm based projects? weak reasoning, as it might just be a supply/demand and not a product quality question
  - Klonoar 11mo ago
    > Why… It’s almost always available resources.
    - MBCook 11mo ago
      Possibly demand as well. We know that Apple operates a whole bunch of Linux servers, do we know if they’re running FreeBSD internally?
zapzupnz 11mo ago
> is it easier in theory to port swift to freebsd rather than linux? the facts that macOs has shared history with freebsd tells me yes That shared history goes back a LONG way. The base components from FreeBSD that are in macOS are absolutely ancient. I think the most modern shared components are just the userland tools. So I don't think it would make much difference at all.
Someone 11mo ago
I don’t know whether you know, but there has been a Linux port for quite a while (https://www.swift.org/blog/swift-linux-port/ https://www.swift.org/blog/swift-linux-port/ is from December 2015). https://www.swift.org/install/linux/ https://www.swift.org/install/linux/ points to https://hub.docker.com/_/swift https://hub.docker.com/_/swift, which has images for Red Hat, Amazon Linux, maybe others.

jiehong 11mo ago

Porting on more platforms is always great, and a good way to find hidden assumptions.

rootnod3 11mo ago

Are they also gonna take the reigns and officially be the maintainer of the FreeBSD package in ports or are they gonna wait for some volunteer to package it for them and choke on the bug reports whenever someone finds an issue?

vtail 11mo ago

Do people use Swift outside of Apple iOS/macOS development in real life? Especially on platforms like Windows/Linux/*BSD?

rootnod3 11mo ago
I guess so. In a way it makes sense if you can share your code base between the iOS/MacOS app and your backend. It makes development easier. But I guess that the majority of apps is not running MacOS servers for the backend. So far it's probably some node backends and all going JSON inbetween. But for some dedicated apps without a web portal inbetween it might be easier if app and backend are both in Swift.
repelsteeltje 11mo ago
Only for iOS apps. Apple does not offer a backend.
- turnsout 11mo ago
  Not true at all. Swift is a very capable backend language, Apple has open sourced a lot of great libraries to power server software development, and there are projects like Vapor [0] that are used in production. [0]: https://vapor.codes https://vapor.codes
  - repelsteeltje 11mo ago
    Ah. You're right, I phrased that ambiguously, sorry. I meant to point out that there is no apple native cloud solution where you can run swift on apple hardware. So if your iOS app needs to talk to a backend that you want to develop and host, you need to run that backend on an OS with cloud support, like Linux, some other Unix or windows. But not macOS or some other "Apple cloud" hosting. For reasons stated above, you might in that case choose Swift.
    - turnsout 11mo ago
      Ah, gotcha—yes, that is actually a pain point and a strange omission. If you need to run backend code for any reason to support your app, Apple literally offers nothing. IBM at one point offered Swift "serverless" lambdas/cloud functions, which made me briefly hopeful that Apple could do the same, but that service was deprecated years ago, and Apple has shown no motion there.

latexr 11mo ago

> The Swift compiler and runtimes have a few dependencies. Please install the following dependencies: > (…) python3 (…) Wait, which part requires Python, and why? And is that only for FreeBSD, or in general? And is that something which will change? Feels very weird that a compiled systems language is dependent on a high-level scripting language.

TheJoeMan 11mo ago
https://github.com/orgs/swiftlang/repositories?q=lang%3Apython&type=all https://github.com/orgs/swiftlang/repositories?q=lang%3Apyth... From a quick look, appears to be the test suite. Which makes sense, hard to validate your language with itself.
- ux266478 11mo ago
  That greatly depends on the codebase and the language. https://github.com/SWI-Prolog/swipl-devel/blob/master/tests/test.pl https://github.com/SWI-Prolog/swipl-devel/blob/master/tests/...
jshier 11mo ago
LLDB also needs python if you want to use its scripting integration.
bananapub 11mo ago
it's not weird at all - you need something sensible to run complicated things while bootstrapping the compiler. Rust does the same thing: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html https://rustc-dev-guide.rust-lang.org/building/how-to-build-...
mshockwave 11mo ago
It's likely that Swift compiler is using LLVM LIT (https://llvm.org/docs/CommandGuide/lit.html https://llvm.org/docs/CommandGuide/lit.html), which is implemented in python, as the test driver
- 11mo ago

hirvi74 11mo ago

I absolutely love Swift. I understand some may disagree, and perhaps many of their arguments are quite valid. However, no language is perfect, and I just feel like Swift has some features that shows that a lot of thought was put into some features -- not to disrespect any other languages. Considering the static typing, guard statements, protocols, lack of ++/-- operators (Lattner's argument was convincing), let/var, being able to make function parameters immutable, being able to lock symbols down to the file level, easy integration with c languages, etc.. I have not used SwiftUI, so I cannot judge it, but I do not think any issues with it are compelling arguments against Swift as a language (that I have read). Lattner is my modern-age programming-hero. I'm glad to see FreeBSD will be able to share the love soon enough.

ezfe 11mo ago
And SwiftUI is not part of Swift open source, it's just for Apple platforms. The underlying Swift language features could be used by other UI systems if someone wanted to make a crossplatform system, though.
myko 11mo ago
Swift is such an excellent language. I hope it continues to grow outside of the Apple ecosystem.
troupo 11mo ago
You can watch Lattner's interview with Theprimeagen. It's a haphazardly designed language where pressure to ship from Apple as a whole overrides any design or development considerations. That's why you end up with a compiler that barfs at even the simplest SwiftUI code because Swift's type system is overly complicated and undecidable. And makes the compiler dog slow. That's why you end up with 200+ keywords [1] with more added each release. That's how you end up with idiocy like `guard let self = self else { return }` (I think they "fixed" this with some syntax sugar) because making if statements understand nulls is beyond the capabilities of heroes apparently. And this is just surface level that immediately came to mind. [1] It's not a typo: https://x.com/jacobtechtavern/status/1841251621004538183 https://x.com/jacobtechtavern/status/1841251621004538183

turnsout 11mo ago

Wow, this is great news. I still don't understand why it has taken so long, when Swift on Linux has been around for 10 years. But as a FreeBSD user, this is very welcome!

fridder 11mo ago

Loving all the new developments with FreeBSD.

kchoudhu 11mo ago

I'm not complaining, but also why?

zapzupnz 11mo ago
Why not? Why wouldn't an open source project want their increasingly platform-agnostic language to be supported on as many platforms as possible?
MBCook 11mo ago
It’s a fantastic language? I’ve come to really like it. Strong type system, is it to work with, lots of resources available, compiles to a binary, interfacing with any other language that you can link to with C, the syntax doesn’t look ugly to me (quite subjective), excellent concurrency support… What can I say I’m a fan.

gocsjess 11mo ago

I believe apple is making OCI-compliant containers which is written in swift. I hope this helps the containerization in FreeBSD.

bartekrutkowski 11mo ago
In what sense? FreeBSD had containers before anyone heard about Docker ;)
- righthand 11mo ago
  Yeah talk about reinventing the wheel so Linux people don’t have to learn a slightly different system (one that is ironically easier to use and better organized than Oci containers).
- Gud 11mo ago
  Jails are not containers.
  - yjftsjthsd-h 11mo ago
    By what definition would LXC be containers and jails not be?
- irusensei 11mo ago
  Jails are great but are not OCI-compliant.
  - jen20 11mo ago
    So? They predate a standard which was basically extracted from Docker.
    - pstuart 11mo ago
      I think the OCI factor being noted here is the packaging not the containerized runtime.

DeathArrow 11mo ago

What can you build with Swift on FreeBSD which isn't easier with other languages?

jhatemyjob 11mo ago
Software that is meant to run on Apple platforms.
- frizlab 11mo ago
  absolutely not
- zapzupnz 11mo ago
  Swift on Apple and Swift on literally-everything-else are very different stories at the moment.
  - frizlab 11mo ago
    Not that different anymore, except Apple-proprietary frameworks (e.g. SwiftUI) are not available outside of Apple platforms.
    - zapzupnz 11mo ago
      This isn't to dispute your assertion, but I think things are still quite a bit different. A lot of things provided by Foundation on macOS are still not available in Linux's Foundation, nor CoreFoundation, so one has to defer to something like Glibc — which, then again, is not available to the static Linux distro. On Windows, it's useful to use WinSDK to do things that Foundation would normally do. There's all sorts of little things that Swift on non-Apple platforms just don't have yet. Little footguns because the Swift rewrite of Foundation isn't quite equivalent yet.
      - frizlab 11mo ago
        It is getting close though, which was my point. Honestly I got bit recently by DateComponentFormatter that does not exists on Linux, but it’s been a while since I’ve had things like that. We even have (NS)AttributedStrings (including the NS version, which I did not expect…). Of course no fonts and co, but that’s AppKit/UIKit/SwiftUI, so it’s normal.

oaiey 11mo ago

A lot of good news recently for swift. I am a bit jealous as my go to language C# / .NET is recently not announcing fancy things. I really like swift going beyond Apple. Particularly the port to android is IMHO crucial, however, now they are in the UI cross platform hell. Let us see if Apple is playing this better than Microsoft. Unfortunately, I have little hope. The only native contenders in the field right now are IMHO are react native and flutter which are both UI toolkits first and language second. Which I find gruesome.

troupo 11mo ago
> I am a bit jealous as my go to language C# / .NET is recently not announcing fancy things. Depends on what you think fancy things are. Both C# and .net are busy releasing a lot of features. You're forgetting that C# is a 25-year-old language at this time. The exciting features they release are things like "access native memory allocation in a GC language", "native Arm64 support", "support for post-quantum cryptography", "tensor support" etc. while already running on all the platforms that Swift is only now announcing as achievements.
- SvenL 11mo ago
  Yeah, also the ecosystem, aspire, ef core, Orleans, ML.NET etc..at this point I don't know what's really missing.
cosmic_cheese 11mo ago
It'd be nice if Apple made SwiftUI cross platform and I'd be singing in the streets if UIKit got ported, but that seems unlikely at best. I believe that there's strong community interest in some kind of Swift UI framework for Android, though, and so there's a substantial chance that a third party solution will appear.
- CharlesW 11mo ago
  skip.tools is one third-party solution for creating Swift + SwiftUI apps for Android today.

ethin 11mo ago

Swift just needs to gain cmake bidirectional support, like, SPM should be able to compile CMake projects and vice-versa, or be able to use vcpkg. Once that's done, I could very much see myself switching to it for a lot of things.

wahnfrieden 11mo ago
SPM support for CMake is in progress
- ethin 11mo ago
  I know, and that's a good thing. That's probably one of the biggest blockers for it's wider adoption. I hope that CMake can eventually get similar abilities for calling into SPM or just outright handling Swift package manifests. That might be too much to ask though.

lukeh 11mo ago

I did try to build a medium sized project with this today. Still a lot of dependencies that will need to be updated for the differences between glibc and libc.