Discussion

ttflee: > Swift 6.3 includes the first official release of the Swift SDK for Android.

gregoriol: That is going to be used... less than Swift for the servers

victorbjorklund: 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: 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.

0x3f: > Swift is designed to be the language you reach for at every layer of the software stack.It's a nice lang for sure, but this will never be true with the way things are. Such wasted opportunity by Apple.

sirwhinesalot: > 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++ filesWhy did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.

frizlab: Dupe: https://news.ycombinator.com/item?id=47510423

dzonga: 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++.

frizlab: How so? I can indeed target every layer of the software stack today using Swift.

rzerowan: 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.

frizlab: A good source of available packages is the Swift Package Index. You can search here packages compatible with Linux[0].[0] https://swiftpackageindex.com/search?query=platform%3Alinux

saagarjha: They had it earlier, as an underscored attribute.

rasmus1610: 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: 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.

willtemperley: 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.

hrmtst93837: 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.

iamcalledrob: 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.

0x3f: 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: 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.