good to see incredible stuff being shipped in Swift. Haven't used it since v3 though.
around 2015-17 - Swift could have easily dethroned Python.
it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
the server ecosystem was starting to come to life, even supported by IBM.
I think the letdown was on the Apple side - they didn't bring in the community fast enough whether on marketing, or messaging - unfortunately Swift has remained largely an Apple ecosystem thing - with complexity now chasing C++.
rasmus1610 52 minutes ago [-]
Maybe Chris Lattner leaving and creating Mojo also didn’t help in that regard.
Swift for TensorFlow was a cool idea in that time …
iamcalledrob 38 minutes ago [-]
That's my read too.
Swift was feeling pretty exciting around ~v3. It was small and easy to learn, felt modern, and had solid interop with ObjC/C++.
...but then absolutely exploded in complexity. New features and syntax thrown in make it feel like C++. 10 ways of doing the same thing. I wish they'd kept the language simple and lean, and wrapped additional complexity as optional packages. It just feels like such a small amount of what the Swift language does actually needs to be part of the language.
willtemperley 13 minutes ago [-]
Which keywords would you get rid of and why? You don't have to use all of them!
eptcyka 37 seconds ago [-]
You can take this approach in personal projects - with teams you need to decide on this and then on-board people into your use of the language. This does not work.
I _can_ do the same with Rust, doesn't mean it's "the language I reach for" for making e.g. a website. Because the tooling, ergonomics, hireability factor, etc. are still very harshly against it.
Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.
zarzavat 27 minutes ago [-]
I don't know why anyone would want to use Apple tools if they are not developing for Apple platforms. Apple barely maintains compatibility for their own platforms, using Swift on a non-Apple platform is setting yourself up for doubule pain.
wwalexander 8 minutes ago [-]
Re: module name selectors, wasn't this already possible, e.g. ModuleA.getValue()? Though I suppose this disambiguates if you also have a type called ModuleA.
sirwhinesalot 1 hours ago [-]
> Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. Annotating a function or enum with @c prompts Swift to include a corresponding declaration in the generated C header that you can include in your C/C++ files
Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.
saagarjha 1 hours ago [-]
They had it earlier, as an underscored attribute.
hrmtst93837 41 minutes ago [-]
C++ interop got attention because it helps Apple absorb low-level codebases that already moved past pure C. Exporting Swift to plain C mostly means more DIY FFI spaghetti.
Once enums, ownership rules, and nullability cross that boundary, the generated header stops looking like a neat bridge and starts looking like one more place for ABI bugs to hide. Closures make it weirder fast, because now your error handling and calling conventions can drift just enough to produce the kind of bug that wastes a whole afernoon.
ttflee 2 hours ago [-]
> Swift 6.3 includes the first official release of the Swift SDK for Android.
It would be really nice if instead we could just do one style of development and then ship a set of libraries as used to work for OpenSTEP (which was why it had "OPEN" in the name).
gregoriol 2 hours ago [-]
That is going to be used... less than Swift for the servers
victorbjorklund 2 hours ago [-]
I don't know. Could be nice for those developers that prioritize iOS and now they could keep writing Swift also for Android.
Is it gonna be what you primarily use if you wanna write an Android app? Probably not.
Is it gonna displace react Native? Probably not. Is it gonna reach the levels of flutter? Maybe.
ChrisMarshallNY 2 hours ago [-]
The language doesn’t really matter. The underlying SDK/framework is where the action is at.
However, I suspect that we may not be too far off, from LLMs being the true cross-platform system. You feed the same requirements, with different targets, and it generates full native apps.
iamcalledrob 55 minutes ago [-]
Interestingly, Kotlin has a pretty solid cross-platform story.
I'd pick it over Swift if targeting Android since it can build and run in the JVM as well as natively -- and has Swift/ObjC interop. Its also very usable on the server if you wanted to, since you can use it in place of Java and tap into the very mature JVM ecosystem. If that's what you're into.
And I have a lot more faith in JetBrains being good stewards of the language rather than Apple, who have a weird collection of priorities.
quangtrn 2 hours ago [-]
[dead]
rzerowan 1 hours ago [-]
Whats the stdlib situation for swift in comparison to newish languages like go or rust. I know its not batteries included lke python - and doesnt have a massive dev ecosystem of helper libs seeming to be mostly tied to macOS/iOS operating system API/ABI.
willtemperley 41 minutes ago [-]
There are still challenges with basics like compression, which tends to involve trawling Github for the least dubious toy project. Even Apple's Compression framework is missing important algorithms like ZSTD.
Another problem is the Apache Software Foundation don't seem to have any Swift maintainers, which means there really aren't any good pure Swift libraries for Arrow or Parquet.
There are some really good open-source libraries from Apple like Swift Collections or Swift Binary Parsing.
frizlab 1 hours ago [-]
A good source of available packages is the Swift Package Index. You can search here packages compatible with Linux[0].
around 2015-17 - Swift could have easily dethroned Python.
it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
the server ecosystem was starting to come to life, even supported by IBM.
I think the letdown was on the Apple side - they didn't bring in the community fast enough whether on marketing, or messaging - unfortunately Swift has remained largely an Apple ecosystem thing - with complexity now chasing C++.
Swift for TensorFlow was a cool idea in that time …
Swift was feeling pretty exciting around ~v3. It was small and easy to learn, felt modern, and had solid interop with ObjC/C++.
...but then absolutely exploded in complexity. New features and syntax thrown in make it feel like C++. 10 ways of doing the same thing. I wish they'd kept the language simple and lean, and wrapped additional complexity as optional packages. It just feels like such a small amount of what the Swift language does actually needs to be part of the language.
Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183
It's a nice lang for sure, but this will never be true with the way things are. Such wasted opportunity by Apple.
E.g. ClearSurgery[0] is written fully in Swift, including the real-time components running on the Linux boxes.
[0] https://clearsurgery.vision
Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.
Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.
Once enums, ownership rules, and nullability cross that boundary, the generated header stops looking like a neat bridge and starts looking like one more place for ABI bugs to hide. Closures make it weirder fast, because now your error handling and calling conventions can drift just enough to produce the kind of bug that wastes a whole afernoon.
For Windows there's a 5 year old blog post: https://www.swift.org/blog/swift-on-windows/
For Linux there's a guide for GNOME: https://www.swift.org/blog/adwaita-swift/
It would be really nice if instead we could just do one style of development and then ship a set of libraries as used to work for OpenSTEP (which was why it had "OPEN" in the name).
Is it gonna be what you primarily use if you wanna write an Android app? Probably not.
Is it gonna displace react Native? Probably not. Is it gonna reach the levels of flutter? Maybe.
However, I suspect that we may not be too far off, from LLMs being the true cross-platform system. You feed the same requirements, with different targets, and it generates full native apps.
I'd pick it over Swift if targeting Android since it can build and run in the JVM as well as natively -- and has Swift/ObjC interop. Its also very usable on the server if you wanted to, since you can use it in place of Java and tap into the very mature JVM ecosystem. If that's what you're into.
And I have a lot more faith in JetBrains being good stewards of the language rather than Apple, who have a weird collection of priorities.
Another problem is the Apache Software Foundation don't seem to have any Swift maintainers, which means there really aren't any good pure Swift libraries for Arrow or Parquet.
There are some really good open-source libraries from Apple like Swift Collections or Swift Binary Parsing.
[0] https://swiftpackageindex.com/search?query=platform%3Alinux