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.
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.
Correct me if im wrong, but isn't the pain points for mobile devs, the need to have intimate knowledge of both pl to build & maintain a good "backend/functionality" of the app over time and that the UI portion of the app is quite simple to learn, build and maintain.
So is it necessary for the swift team to try get swift ui onto android, versus a developer building their app "backend/functionality" in swift, compiling it down for both ios and android, then bridging the android bindings with a UI made in kmp etc
I recently learnt that amo and protonmail use this solution but instead of swift android, they were using uniffi-rs and seemed to have great results, I think proton ditched react native for this solution, which to me sounds like a more streamlined way of getting native performance without needing the overhead of managing multiple language. I guess we will have to see how mature swift android gets and if it can replace uniffi-rs etc which would save even more time
I’d absolutely love it if they made SwiftUI cross platform for both mobile and desktop. Flutter is nice but it’s still sort of a mess sometimes when targeting desktop instead of mobile.
UIKit is very mature and tied to the iOS ecosystem and a bit more complex. SwiftUI is easier to port (since it is still a incomplete / subset features of UIKit).
> 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.
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.
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.
Some anecdotal evidence of its terrible qualities are the major degradation of software quality in the Apple ecosystem.
In particular the rewrites or brand new softwares feel much worse than it used to be.
I feel like if it was a good language, it should make things better; of course there may be some other confounding factors but it's hard to not link the software quality problem to the Swift push.
Oh, sick! Thank you for bring this to my attention. I didn't even know this interview existed. I watched Lattner's three interviews with Lex (though I'm not a indifferent about Lex). I do love Theprimeagen though -- he represents us neurodiverse devs well.
> a compiler that barfs at even the simplest SwiftUI code
I have never used Swift UI. I honestly have used Swift mainly for automating a lot of stuff I used to do with Applescript or little scripts for minor things. I have never actually used Swift for any GUI application development.
> That's why you end up with 200+ keywords [1] with more added each release.
Sure, like I previously said, no language is perfect. I am less concerned about the number of total keywords vs. the average number of keywords required to accomplish what I need. I do not feel like I honestly have had to use any more than what I commonly user in .NET/C#. In fact, I think C# might honestly be worse.
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.
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?
> 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.
Python and LIT are used heavily to build and test the compiler, but that is only for building it, you do not need it to download and use the built toolchain. The python dependency is more about its use in LLDB.
Thats cool I knew those were coming but the most interesting thing in here is that it seems to be running the Linux images under the Linuxlator (hence he had to enable the linux service) as opposed to creating a Linux VM like the other operating system do. Pretty cool!
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).
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 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.
Readit News
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 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.
So is it necessary for the swift team to try get swift ui onto android, versus a developer building their app "backend/functionality" in swift, compiling it down for both ios and android, then bridging the android bindings with a UI made in kmp etc
I recently learnt that amo and protonmail use this solution but instead of swift android, they were using uniffi-rs and seemed to have great results, I think proton ditched react native for this solution, which to me sounds like a more streamlined way of getting native performance without needing the overhead of managing multiple language. I guess we will have to see how mature swift android gets and if it can replace uniffi-rs etc which would save even more time
It's a nearly impossible task. Just ask Qt, who have been at this for thirty years.
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.
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/
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.
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)
just mixing appkit and language in the same phrase implies swift.
It was a simpler Swift, I could understand all of it. Just look at the explosion of keywords in Swift.
Dead Comment
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
I feel like if it was a good language, it should make things better; of course there may be some other confounding factors but it's hard to not link the software quality problem to the Swift push.
Oh, sick! Thank you for bring this to my attention. I didn't even know this interview existed. I watched Lattner's three interviews with Lex (though I'm not a indifferent about Lex). I do love Theprimeagen though -- he represents us neurodiverse devs well.
> a compiler that barfs at even the simplest SwiftUI code
I have never used Swift UI. I honestly have used Swift mainly for automating a lot of stuff I used to do with Applescript or little scripts for minor things. I have never actually used Swift for any GUI application development.
> That's why you end up with 200+ keywords [1] with more added each release.
Sure, like I previously said, no language is perfect. I am less concerned about the number of total keywords vs. the average number of keywords required to accomplish what I need. I do not feel like I honestly have had to use any more than what I commonly user in .NET/C#. In fact, I think C# might honestly be worse.
https://github.com/e3b0c442/keywords
> `guard let self = self else { return }`
I think you can do something like this as Swift 5 or 6:
`guard let self else { return }`
Don't quote me though (It's also not much better looking, imo).
> (…) 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.
https://github.com/SWI-Prolog/swipl-devel/blob/master/tests/...