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)
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?
Yes, because Apple gave up on the server market, so that demography usually uses Linux based servers and does code sharing between backend and their iDevices apps.
> 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.
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.
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.
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!
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…
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.
I guess it's a matter of perspective. Dotnet 10 just came out[1] with a bunch of solid new shiny that I'm enjoying.
And, as it stands, Dotnet is much further along in the multi-platform game than Swift. As far as I know, none of the Swift-based UI stuff is being ported to, let alone going to be usable on non-Apple platforms.
> The only native contenders in the field right now are IMHO are [...] and flutter
I wouldn't really call Flutter "native".
I don't have a strong enough grasp of where React Native is at now. It was severely lacking when I looked at it circa 2018. But then we needed to call in to our own native code libraries, so we were probably quite niche.
Xamarin.Forms worked well enough, but the transition to MAUI has been full of woe and even more bugs and weird edge case functionality than Xamarin had.
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.
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.
27 comments
[ 3.7 ms ] story [ 52.9 ms ] threadalso, congrats, the swift and freebsd are ambitious in terms of new deployment platforms and compatibility! (see embedded swift, oci freebsd containers, freebsd on firecracker)
https://www.swift.org/install/linux/ points to https://hub.docker.com/_/swift, which has images for Red Hat, Amazon Linux, maybe others.
> (…) 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.
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.
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
What can I say I’m a fan.
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.
And, as it stands, Dotnet is much further along in the multi-platform game than Swift. As far as I know, none of the Swift-based UI stuff is being ported to, let alone going to be usable on non-Apple platforms.
1. https://www.c-sharpcorner.com/article/whats-new-in-net-10/
Flutter is not a language.
https://en.wikipedia.org/wiki/Flutter_(software)
From that page:
>Flutter apps are written in the Dart language.
>https://en.wikipedia.org/wiki/Dart_(programming_language)
It was a simpler Swift, I could understand all of it. Just look at the explosion of keywords in Swift.
I wouldn't really call Flutter "native".
I don't have a strong enough grasp of where React Native is at now. It was severely lacking when I looked at it circa 2018. But then we needed to call in to our own native code libraries, so we were probably quite niche.
Xamarin.Forms worked well enough, but the transition to MAUI has been full of woe and even more bugs and weird edge case functionality than Xamarin had.