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.
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.
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/...
It’s also weird to include Java and Swift in that list considering both afaik are maintained by a separate foundation. Java from Sun is even predominantly basically OpenJDK with some remaining proprietary Sun / Oracle bits but it’s the reference open source implementation used by most everyone.
Ladybird browser team planned to start using Swift in their codebase, but it hasn't happen yet.
> Ladybird browser team planned to start using Swift in their codebase, but it hasn't happen yet.
But I think “why” remains a valid question when you could make a safe pick like Node, Python etc. I really like Swift as a language but I’d still struggle to justify using it outside of iOS.
Dead projects are
- Kitura https://github.com/Kitura/Kitura
- Perfect https://github.com/PerfectlySoft/Perfect
Don't know of large organizations using it in production, the vibe I get is that it's useful for an iOS developer who wants to deploy a small server for their product without learning Python or Javascript.
You could certainly use it at larger scale, but you have to justify giving up the big ecosystems of its competitors.
As far as I know there is no clear boundary between safe and unsafe.
It's been two years since I was an iOSSwift programmer, but the concurrent/parallel facilities were quite woeful. Memory protection no nonexsistant
I do not miss it. This might be useful for porting Apple software, but do not start new projects with it.
Plus, most of the open source libs are one person's weekend projects, from 3 years ago...
It's a great language, but nowadays tooling/ecosystem and build systems are key to success.
Worth noting that Gradle's long list of capabilities can sometimes be as much of a liability (or at least a frustration) as it is a boon. A great many projects don't need even a fifth of its complexity.
[0]: https://vapor.codes
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)
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.
weak reasoning, as it might just be a supply/demand and not a product quality question
https://www.swift.org/install/linux/ points to https://hub.docker.com/_/swift, which has images for Red Hat, Amazon Linux, maybe others.
What can I say I’m a fan.