8 ms·

Swift 6.3

340 points by ingve 7mo ago

ttflee 7mo ago
> Swift 6.3 includes the first official release of the Swift SDK for Android.
- gregoriol 7mo ago
  That is going to be used... less than Swift for the servers
  - wiseowise 7mo ago
    This is going to be used much more than Swift for servers. Swift is a primarily client-side mobile language. It makes sense that you tap into reusing the logic.
  - victorbjorklund 7mo 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 7mo 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.
      - p2detar 7mo ago
        > from LLMs being the true cross-platform system Fully agree. I have zero Swift knowledge and currently use LLM to write a native app. I'm well aware of the SDKs and concepts in iOS development, so even if something's wrong I got intuition where to look and how to make the LLM fix it.
      - tonyedgecombe 7mo ago
        I’m not sure about that but porting libraries from one language to another seems well within their capabilities.
        ChrisMarshallNY 7mo ago
        I don't think we're there yet, but I suspect that it's just a matter of time. It would certainly be quite profitable. Money tends to drive progress.
    - wiseowise 7mo ago
      > Is it gonna reach the levels of flutter? Maybe. Never. It won’t even reach Compose level, Flutter level DX is unattainable for any framework outside Flutter.
  - quangtrn 7mo ago
    [flagged]
  - iamcalledrob 7mo 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.
    - ljm 7mo ago
      Kotlin is practically a no-brainer when you have JVM at your finger tips, versus something like Swift which is comparatively young. I tried to use Vapor with Swift recently and struggled to get something working because the documentation looked comprehensive, but had a lot of gaps. I ended up throwing it out because I didn't have the time to dig through the source to understand how to do something, when I could use a mature framework in any other language instead. The promise is there but I'm just not ready to invest. My youthful days of unbounded curiosity are coming to an end and these days I just want to get something done without much faff.
      - well_ackshually 7mo ago
        Mind you, Kotlin/Native (which is what gets used when you're compiling for iOS) doesn't have access to the JVM. However, the Kotlin community is fundamentally all about open source, whereas Apple & iOS Devs have an allergy to it. The quality and quantity is already miles above the vast majority of what's in the Swift ecosystem. https://klibs.io https://klibs.io has all the native compatible libs. And if you're targeting a platform where the JVM is available then yeah, it's massive. Compose makes UI tolerable compared to JWT too. Even large projects like Spring are Kotlin first nowadays.
        wiseowise 7mo ago
        JetBrains has monetary interest in promoting Kotlin beyond Android, there’s zero incentive to promote Swift as the language outside of iOS and Mac. They don’t need to capture minds of devs for them to develop for Apple devices.
  - rirze 7mo ago
    Just like .NET for linux... right? RIGHT?
    - jkman 7mo ago
      At least a very common .NET web app framework is often deployed on linux. Powershell for linux might be more apt lol
- WillAdams 7mo ago
  Anything similar for Windows and Linux? For Windows there's a 5 year old blog post: https://www.swift.org/blog/swift-on-windows/ https://www.swift.org/blog/swift-on-windows/ For Linux there's a guide for GNOME: https://www.swift.org/blog/adwaita-swift/ 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).
  - myko 7mo ago
    I haven't shipped any Swift on Windows myself but I have a production Linux system using Swift (and C++ interop) and it works really well
  - migueldeicaza 7mo ago
    Swift on Windows has been part of the official distribution for a long time: https://www.swift.org/install/windows/ https://www.swift.org/install/windows/
    - WillAdams 7mo ago
      The blog posts seems to place higher on search results --- maybe arrange to have it edited? Which GUI toolkit(s) does that install support?
      - fassssst 7mo ago
        None, you’re on your own. The Browser Company made bindings for WinRT so you can use WinUI imperatively but it’s non trivial to set up.
0x3f 7mo ago
> 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.
- frizlab 7mo ago
  How so? I can indeed target every layer of the software stack using Swift, today. E.g. ClearSurgery[0] is written fully in Swift, including the real-time components running on the Linux boxes. [0] https://clearsurgery.vision https://clearsurgery.vision
  - zarzavat 7mo 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.
    - frizlab 7mo ago
      That was true for Swift 2, maybe a little for Swift 3, but it has not been true since a long time now…
      - hu3 7mo ago
        If cross platform support took so long, it's a major red flag. Plus Swift is arguably too unnecessarily complex now. And there's Rust/Zig so why use Swift for low level?
        myHNAccount123 7mo ago
        https://github.com/finagolfin/swift-android-sdk https://github.com/finagolfin/swift-android-sdk At least 6 years old.
        hirvi74 7mo ago
sirwhinesalot 7mo 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 7mo ago
  They had it earlier, as an underscored attribute.
- hrmtst93837 7mo ago
  [flagged]
- asimovDev 7mo ago
  it's been there for a while as an experimental feature. I used it in a project
- dagmx 7mo ago
  You already had ObjC export so it was arguably low priority given the crossover
rzerowan 7mo 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.
- frizlab 7mo ago
  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 https://swiftpackageindex.com/search?query=platform%3Alinux
  - marcprux 7mo ago
    And also Android[1]! [1] https://swiftpackageindex.com/search?query=platform%3Aandroid https://swiftpackageindex.com/search?query=platform%3Aandroi...
- willtemperley 7mo 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.
  - marcprux 7mo ago
    > There are still challenges with basics like compression FWIW, there is an active discussion on this very topic: https://forums.swift.org/t/proposal-compression-library/85413 https://forums.swift.org/t/proposal-compression-library/8541...
    - willtemperley 7mo ago
dzonga 7mo ago
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 7mo 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 …
  - troupo 7mo ago
    Lattner probably left because Apple didn't give the team any breathing room to properly implement the language. It was "we must have this feature yesterday". A lot of Swift is the equivalent of Javascrip's "we have 10 days to implement and ship it": https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400 https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400 --- start quote --- Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff... We had a ton of users, it had a ton of iternal technical debt... the whole team was behind, and instead of fixing the core, what the team did is they started adding all these special cases. --- end quote ---
    - groundzeros2015 7mo ago
      For this language to become default at Apple they had to be doing a massive amount of internal promotion - in other words they knew where it was going. And then if that's the case, how were they not ready to solve the many problems that a big organization would run into? And all the schedule constraints that come with it?
    - 7mo ago
deleted 7mo ago
[deleted]
wwalexander 7mo 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.
- jshier 7mo ago
  Yes, exactly. It also allows you to disambiguate overloaded function. e.g. thing.ModuleA::doThing() vs. thing.ModuleB::doThing(), which wasn't possible with the previous syntax.
vanyaland 7mo ago
[dead]
troupo 7mo ago
> @c @specialized @inline(always) @export(implementation) Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183 https://x.com/jacobtechtavern/status/1841251621004538183
- Batbird 7mo ago
  I remember jumping into Swift from Obj-C in 2014 and using words like "beautiful" and "expressive" to describe syntax, and saying things like "you can tell what language someone is coming from by how they code in Swift". Now it's grown as it has - sometimes feels like season 4 of Lost. Makes me feel old too.
TekMol 7mo ago
Swift reminds me a lot of Flash back in the day. While the Flash guys had to use a native development environment and compile their stuff, I could just edit JavaScript in a plain text file and hit reload. 20 years later, and some of the same friends now swear by Swift. And have to use a native development environment and compile their stuff. While I still prefer to just edit JavaScript in a plain text file and hit reload.
- wiseowise 7mo ago
  Given that Swift has one of the slowest compilation times, this is a valid criticism.
Serhii-Set 7mo ago
[flagged]
drzaiusx11 7mo ago
No mention of compilation speed improvements? Very unfortunate. Compilation times slower than rust really hampers the devx of this otherwise decent language.
- roflcopter69 7mo ago
  I tried Swift a few months ago in a project that made use of a bunch of bigger dependencies and I was instantly shocked by the compilation times. It's quite unimaginable to me using Swift for everyday work because of that. Especially when coming from the fast compile times of Go. But it's really unfortunate because I really enjoyed writing Swift because it feels like a very well made language. But iterating on some code and trying to get quick feedback is pure pain.
  - wahnfrieden 7mo ago
    Tuist is necessary for substantial projects
asimovDev 7mo ago
I remember building dylibs in Swift for use in C programs, had to use @cdecl annotation iirc to achieve that, which was experimental. Good to see it's finally official
rubymamis 7mo ago
I'm glad Chris Lattner moved on and founded Mojo. It's such a cool language with ton of potential.
- wycy 7mo ago
  I was excited about it when it first came out, but haven't heard anything about it since.
dbvn 7mo ago
I want to like swift so bad
fithisux 7mo ago
Lack of Mingw support keeps me away from it, and Odin.
gloosx 7mo ago
>nocopy for disabling copy-to-clipboard Im curious how is this used?
- OnionBlender 7mo ago
  It is a markdown thing. It removes the "copy" button from the code block when the markdown is rendered. Search for "nocopy" on this page. https://docs.instruqt.com/tracks/challenges/using-markdown-editor#code-blocks https://docs.instruqt.com/tracks/challenges/using-markdown-e...
jbverschoor 7mo ago
In an effort to use swift for scripting, without the startup cost: Swift Caching Compiler - https://github.com/jrz/tools https://github.com/jrz/tools
mathverse 7mo ago
Swift lives only for macOS,iOS and besides those ecosystems does not have a solid and robust ecosystem to be used for anything else. It's a shame but it for sure needs BigTech for it to be used anywhere else.
- hirvi74 7mo ago
  I still have hope Swift will break free like C# has. I hope one day something like Vapor or Kitura takes off.
  - mathverse 7mo ago
    If Swift was paired with smh like QT/GTK (could have replaced Vala) it would've been interesting.
    - classified 7mo ago
      smh?
      - velocity3230 7mo ago
        "something"
        steve1977 7mo ago
        Wouldn't that be smth and smh is "shaking my head"? I'm not a native English speaker, just interested in the vernacular.
    - presbyterian 7mo ago
      It has been: https://www.swift.org/blog/adwaita-swift/ https://www.swift.org/blog/adwaita-swift/
  - steve1977 7mo ago
    I guess what Swift misses compared to C# is enterprise usage.
hirvi74 7mo ago
The Lord's language keeps getting better and better. The easier C interop could not have come at a more serendipitous time in my life.
lijunle 7mo ago
How is the toolchain? Does Swift Lint and Swift Format support the newest version. Honestly, the modern program language should have the built-in formatter and recommend lint rules. It is not just shipping a program language, it is a while ecosystem.
- qn9n 7mo ago
  Both are apart of the toolchain now, no external dependencies required: `swift format` and `swift format lint` to access them
  - jshier 7mo ago
    SwiftLint and SwiftFormat are different tools than swift-format, which is what is included with Swift itself. swift-format is less capable than either, or similar tools from other ecosystems. Personally I use the other two. And they don't usually require updates for new language versions, and when they do, they update quickly, as they aren't part of the Swift toolchain and subject to its glacial release process.
pkpowell 7mo ago
Anyone else think the weather in the screen shot at the top of the page is a bit off? Snow in Lisbon (apparently it snowed there once in 2006), rain in Reykjavik at -1°. AI slop?
- sheept 7mo ago
  If you look at the code above, the temperature and weather are selected independently randomly. That alone is not indicative of AI-generated code; a human could write something similar for demo/learning purposes.
- deleted 7mo ago
  [deleted]
slopinthebag 7mo ago
Swift truly is one of the languages of all time. I started a mobile app with the UI built in Swift and the core in Rust. The amount of implicit and hidden behaviour, magical fields being generated on objects because of certain annotations, the massive amount of @decorators...it's too much. I'm going to have an LLM generate the SwiftUI and touch as little of it as possible. It's also strange because before I learned Swift, I heard about how beautiful it is but I find it much noisier than Rust.
- qn9n 7mo ago
  I find rust much noisier, especially at its basics where you write “for item in items” instead of using iter()
  - slopinthebag 7mo ago
    Idk, I don't swift is objectively noisy but there is something about reading it that just hurts my brain. Stuff like ForEach(vm.sorted(by: \.name)) { user in row(for: user) } \. looks like a syntax error to me, wtf. Also, "in" instead of -> ??? .padding(.vertical, 4) I also really dislike how you can leave off the type name, meaning you never actually know what that Type is unless you literally inspect the signature of the caller. func sorted(by keyPath: KeyPath<User, String>) -> [User] { users.sorted { $0[keyPath: keyPath] < $1[keyPath: keyPath] } } ??? Yeah I fully accept it's just a me problem. But I hate it haha.
- ChadNauseam 7mo ago
  What are you using for rust-swift interop?
  - slopinthebag 7mo ago
    uniffi
- trevor-e 7mo ago
  >I heard about how beautiful it is This used to be the case around Swift 4, but since then they've added so many features and keywords to the language. Now the simplicity and elegance is gone. Also it seems like there was a marked change in the culture of Swift. It somehow attracted a lot of the "ackchyually" crowd which resulted in a lot of massively complicated features. I liked to occasionally browse the evolution docs and they got more and more complex over time.
mikusnuz 7mo ago
The noncopyable types improvements are the most underrated part of this release. Finally makes it practical to model unique ownership in Swift without fighting the compiler.
gigatexal 7mo ago
My chances of landing at Apple increased when they launched Swift. I am too dumb to learn objective C but swift I can do.
cdcarter 7mo ago
I spent last week (with Opus, of course) porting the xv6-riscv teaching operating system to a bunch of different languages. Zig, Nim, LISP, and Swift. The improvements in embedded Swift have definitely made it one of the most enjoyable/productive languages to work on the OS. I feel like I can build useful abstractions that wrap raw memory access and make the userland code feel very neat. On the other hand, the compilation times are SO bad, that I'm really focusing on the Nim port anyway.
- sspiff 7mo ago
  It's been a long time since I came across Nim. I thought it was really interesting about 12 years ago. What made you land on Nim instead of any of the more obvious alternatives?
  - cdcarter 7mo ago
    I was looking for something that allows easy access to direct memory, with a syntax thats a little easier to explain than C. Frankly, zig was not actually a real viable option based on that syntax requirement but I still wanted to explore it. Nim really is clean and simple.
    - PKop 7mo ago
      How about Odin?
    - functional_dev 7mo ago
      yeah, Nim is great for that... much easier to explain to others than C or Zig especially for math code
    - flykespice 7mo ago
      Yeah, for a language that claims to be a better modern alternative to C, zig verbose syntax is really an eyesore to look at compared the very same codebase written in C... I lost immediately any interest on it
    - seanw444 7mo ago
jwlake 7mo ago
did they ever add #define? bridging constants from the build system to swift with static NSString * const kConstValue = @XSTR(CONST_VALUE); is soooo annoying.
- fingerlocks 7mo ago
  Only integers for #defines in C-headers, enabled with a recent-ish compiler flag. Swift has a #define but it’s just an ifdef list of flags assigned to one compiler setting. But you can bridge build setting variables using some clever xcconfig macros that combine both preprocessor systems.
vladde 7mo ago
i worked with SwiftUI for about two years, and i think it's a really nice language. the compiler is very slow though. but i think it's too coupled to Apple still. when i tried getting anything running on non-Apple, i had so much trouble i decided then to not even bother.
- wahnfrieden 7mo ago
  skip.dev helps
MrTomatoes 7mo ago
Nice update, but it's a shame I can't write on it, not because I don't want to, but because it doesn't support it.
- MrTomatoes 7mo ago
  but still a good update
w10-1 7mo ago
Beyond the marketing view... here are the (incomplete) changes: https://github.com/swiftlang/swift/blob/main/CHANGELOG.md Here are the evolution proposals that landed in 6.3: https://www.swift.org/swift-evolution/#?search=6.3 Overall 6.3 ended up mostly about integration: stdlib, c/c++ (often driven by swift-java interop needs), and builds. SPM (swift package manager) is slowly reaching out to take over xcode build features (e.g., resources most recently), and they have been inching and hacking their way to a new swift-build engine (now experimental) and "prebuilt" modules for the compiler/IDE macro support. Things Go Wrong all the time when trying to replace parts while driving, and there's very little visibility or control over the interactions between SPM and Xcode. Conversely to integrations, endogenous language progress seems relatively quiet because there's a lot of behind-the-scenes work extending the initial blush of lifetime controls to iterators, stdlib types, etc. (never mind parameter packs). They're in year 4+ of building out the function-coloring of concurrency and isolation domains (6.2 had an "easy" mode that caused lots of problems), so adding year 2+ dataflow coloring of lifetimes is doubly complicating. Naturally, diverse support for exciting new features results in quite a spread in the third-party library ecosystem of support for various language features. And now with AI entrepreneurs rewriting and porting any project that can score hits and kudos, the usual open-source authorities are losing their steam. Finally, there's the baseline platform complexity of multiple OS and devices, physical and simulator debugging support, cloud CI... So: that makes four dimensions of complexity. As a Swift developer you'd have to be very careful to stay on a working path as things shift underneath you. All for the love of it?
- jshier 7mo ago
  Looks like swift-build will be the default in Swift 6.4: https://forums.swift.org/t/swiftpm-development-update-default-build-system-change/85548/ https://forums.swift.org/t/swiftpm-development-update-defaul... Unfortunately, swift-build is what Xcode has been using for years now, and has major performance issues: https://forums.swift.org/t/target-dependency-graph-computation-performance-too-slow/81552/11 https://forums.swift.org/t/target-dependency-graph-computati... Perhaps using it in both SPM and Xcode will lead to improvements, but I'm not especially optimistic.
  - 7mo ago
chrismsimpson 7mo ago
Okay so the module import thing is interesting and feels like 1) it should have been included on day one and 2) might have made Swift more viable for projects like Ladybug

Swift 6.3

340 points by ingve 7mo ago

ttflee 7mo ago

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

gregoriol 7mo ago
That is going to be used... less than Swift for the servers
- wiseowise 7mo ago
  This is going to be used much more than Swift for servers. Swift is a primarily client-side mobile language. It makes sense that you tap into reusing the logic.
- victorbjorklund 7mo 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 7mo 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.
    - p2detar 7mo ago
      > from LLMs being the true cross-platform system Fully agree. I have zero Swift knowledge and currently use LLM to write a native app. I'm well aware of the SDKs and concepts in iOS development, so even if something's wrong I got intuition where to look and how to make the LLM fix it.
    - tonyedgecombe 7mo ago
      I’m not sure about that but porting libraries from one language to another seems well within their capabilities.
      - ChrisMarshallNY 7mo ago
        I don't think we're there yet, but I suspect that it's just a matter of time. It would certainly be quite profitable. Money tends to drive progress.
  - wiseowise 7mo ago
    > Is it gonna reach the levels of flutter? Maybe. Never. It won’t even reach Compose level, Flutter level DX is unattainable for any framework outside Flutter.
- quangtrn 7mo ago
  [flagged]
- iamcalledrob 7mo 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.
  - ljm 7mo ago
    Kotlin is practically a no-brainer when you have JVM at your finger tips, versus something like Swift which is comparatively young. I tried to use Vapor with Swift recently and struggled to get something working because the documentation looked comprehensive, but had a lot of gaps. I ended up throwing it out because I didn't have the time to dig through the source to understand how to do something, when I could use a mature framework in any other language instead. The promise is there but I'm just not ready to invest. My youthful days of unbounded curiosity are coming to an end and these days I just want to get something done without much faff.
    - well_ackshually 7mo ago
      Mind you, Kotlin/Native (which is what gets used when you're compiling for iOS) doesn't have access to the JVM. However, the Kotlin community is fundamentally all about open source, whereas Apple & iOS Devs have an allergy to it. The quality and quantity is already miles above the vast majority of what's in the Swift ecosystem. https://klibs.io https://klibs.io has all the native compatible libs. And if you're targeting a platform where the JVM is available then yeah, it's massive. Compose makes UI tolerable compared to JWT too. Even large projects like Spring are Kotlin first nowadays.
      - wiseowise 7mo ago
        JetBrains has monetary interest in promoting Kotlin beyond Android, there’s zero incentive to promote Swift as the language outside of iOS and Mac. They don’t need to capture minds of devs for them to develop for Apple devices.
- rirze 7mo ago
  Just like .NET for linux... right? RIGHT?
  - jkman 7mo ago
    At least a very common .NET web app framework is often deployed on linux. Powershell for linux might be more apt lol
WillAdams 7mo ago
Anything similar for Windows and Linux? For Windows there's a 5 year old blog post: https://www.swift.org/blog/swift-on-windows/ https://www.swift.org/blog/swift-on-windows/ For Linux there's a guide for GNOME: https://www.swift.org/blog/adwaita-swift/ 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).
- myko 7mo ago
  I haven't shipped any Swift on Windows myself but I have a production Linux system using Swift (and C++ interop) and it works really well
- migueldeicaza 7mo ago
  Swift on Windows has been part of the official distribution for a long time: https://www.swift.org/install/windows/ https://www.swift.org/install/windows/
  - WillAdams 7mo ago
    The blog posts seems to place higher on search results --- maybe arrange to have it edited? Which GUI toolkit(s) does that install support?
    - fassssst 7mo ago
      None, you’re on your own. The Browser Company made bindings for WinRT so you can use WinUI imperatively but it’s non trivial to set up.

0x3f 7mo ago

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

frizlab 7mo ago
How so? I can indeed target every layer of the software stack using Swift, today. E.g. ClearSurgery[0] is written fully in Swift, including the real-time components running on the Linux boxes. [0] https://clearsurgery.vision https://clearsurgery.vision
- zarzavat 7mo 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.
  - frizlab 7mo ago
    That was true for Swift 2, maybe a little for Swift 3, but it has not been true since a long time now…
    - hu3 7mo ago
      If cross platform support took so long, it's a major red flag. Plus Swift is arguably too unnecessarily complex now. And there's Rust/Zig so why use Swift for low level?
      - myHNAccount123 7mo ago
        https://github.com/finagolfin/swift-android-sdk https://github.com/finagolfin/swift-android-sdk At least 6 years old.
      - hirvi74 7mo ago

sirwhinesalot 7mo 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 7mo ago
They had it earlier, as an underscored attribute.
hrmtst93837 7mo ago
[flagged]
asimovDev 7mo ago
it's been there for a while as an experimental feature. I used it in a project
dagmx 7mo ago
You already had ObjC export so it was arguably low priority given the crossover

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

frizlab 7mo ago
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 https://swiftpackageindex.com/search?query=platform%3Alinux
- marcprux 7mo ago
  And also Android[1]! [1] https://swiftpackageindex.com/search?query=platform%3Aandroid https://swiftpackageindex.com/search?query=platform%3Aandroi...
willtemperley 7mo 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.
- marcprux 7mo ago
  > There are still challenges with basics like compression FWIW, there is an active discussion on this very topic: https://forums.swift.org/t/proposal-compression-library/85413 https://forums.swift.org/t/proposal-compression-library/8541...
  - willtemperley 7mo ago

dzonga 7mo ago

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 7mo 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 …
- troupo 7mo ago
  Lattner probably left because Apple didn't give the team any breathing room to properly implement the language. It was "we must have this feature yesterday". A lot of Swift is the equivalent of Javascrip's "we have 10 days to implement and ship it": https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400 https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400 --- start quote --- Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff... We had a ton of users, it had a ton of iternal technical debt... the whole team was behind, and instead of fixing the core, what the team did is they started adding all these special cases. --- end quote ---
  - groundzeros2015 7mo ago
    For this language to become default at Apple they had to be doing a massive amount of internal promotion - in other words they knew where it was going. And then if that's the case, how were they not ready to solve the many problems that a big organization would run into? And all the schedule constraints that come with it?
  - 7mo ago

deleted 7mo ago

[deleted]

wwalexander 7mo 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.

jshier 7mo ago
Yes, exactly. It also allows you to disambiguate overloaded function. e.g. thing.ModuleA::doThing() vs. thing.ModuleB::doThing(), which wasn't possible with the previous syntax.

vanyaland 7mo ago

[dead]

troupo 7mo ago

> @c @specialized @inline(always) @export(implementation) Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183 https://x.com/jacobtechtavern/status/1841251621004538183

Batbird 7mo ago
I remember jumping into Swift from Obj-C in 2014 and using words like "beautiful" and "expressive" to describe syntax, and saying things like "you can tell what language someone is coming from by how they code in Swift". Now it's grown as it has - sometimes feels like season 4 of Lost. Makes me feel old too.

TekMol 7mo ago

Swift reminds me a lot of Flash back in the day. While the Flash guys had to use a native development environment and compile their stuff, I could just edit JavaScript in a plain text file and hit reload. 20 years later, and some of the same friends now swear by Swift. And have to use a native development environment and compile their stuff. While I still prefer to just edit JavaScript in a plain text file and hit reload.

wiseowise 7mo ago
Given that Swift has one of the slowest compilation times, this is a valid criticism.

Serhii-Set 7mo ago

[flagged]

drzaiusx11 7mo ago

No mention of compilation speed improvements? Very unfortunate. Compilation times slower than rust really hampers the devx of this otherwise decent language.

roflcopter69 7mo ago
I tried Swift a few months ago in a project that made use of a bunch of bigger dependencies and I was instantly shocked by the compilation times. It's quite unimaginable to me using Swift for everyday work because of that. Especially when coming from the fast compile times of Go. But it's really unfortunate because I really enjoyed writing Swift because it feels like a very well made language. But iterating on some code and trying to get quick feedback is pure pain.
- wahnfrieden 7mo ago
  Tuist is necessary for substantial projects

asimovDev 7mo ago

I remember building dylibs in Swift for use in C programs, had to use @cdecl annotation iirc to achieve that, which was experimental. Good to see it's finally official

rubymamis 7mo ago

I'm glad Chris Lattner moved on and founded Mojo. It's such a cool language with ton of potential.

wycy 7mo ago
I was excited about it when it first came out, but haven't heard anything about it since.

dbvn 7mo ago

I want to like swift so bad

fithisux 7mo ago

Lack of Mingw support keeps me away from it, and Odin.

gloosx 7mo ago

>nocopy for disabling copy-to-clipboard Im curious how is this used?

OnionBlender 7mo ago
It is a markdown thing. It removes the "copy" button from the code block when the markdown is rendered. Search for "nocopy" on this page. https://docs.instruqt.com/tracks/challenges/using-markdown-editor#code-blocks https://docs.instruqt.com/tracks/challenges/using-markdown-e...

jbverschoor 7mo ago

In an effort to use swift for scripting, without the startup cost: Swift Caching Compiler - https://github.com/jrz/tools https://github.com/jrz/tools

mathverse 7mo ago

Swift lives only for macOS,iOS and besides those ecosystems does not have a solid and robust ecosystem to be used for anything else. It's a shame but it for sure needs BigTech for it to be used anywhere else.

hirvi74 7mo ago
I still have hope Swift will break free like C# has. I hope one day something like Vapor or Kitura takes off.
- mathverse 7mo ago
  If Swift was paired with smh like QT/GTK (could have replaced Vala) it would've been interesting.
  - classified 7mo ago
    smh?
    - velocity3230 7mo ago
      "something"
      - steve1977 7mo ago
        Wouldn't that be smth and smh is "shaking my head"? I'm not a native English speaker, just interested in the vernacular.
  - presbyterian 7mo ago
    It has been: https://www.swift.org/blog/adwaita-swift/ https://www.swift.org/blog/adwaita-swift/
- steve1977 7mo ago
  I guess what Swift misses compared to C# is enterprise usage.

hirvi74 7mo ago

The Lord's language keeps getting better and better. The easier C interop could not have come at a more serendipitous time in my life.

lijunle 7mo ago

How is the toolchain? Does Swift Lint and Swift Format support the newest version. Honestly, the modern program language should have the built-in formatter and recommend lint rules. It is not just shipping a program language, it is a while ecosystem.

qn9n 7mo ago
Both are apart of the toolchain now, no external dependencies required: `swift format` and `swift format lint` to access them
- jshier 7mo ago
  SwiftLint and SwiftFormat are different tools than swift-format, which is what is included with Swift itself. swift-format is less capable than either, or similar tools from other ecosystems. Personally I use the other two. And they don't usually require updates for new language versions, and when they do, they update quickly, as they aren't part of the Swift toolchain and subject to its glacial release process.

pkpowell 7mo ago

Anyone else think the weather in the screen shot at the top of the page is a bit off? Snow in Lisbon (apparently it snowed there once in 2006), rain in Reykjavik at -1°. AI slop?

sheept 7mo ago
If you look at the code above, the temperature and weather are selected independently randomly. That alone is not indicative of AI-generated code; a human could write something similar for demo/learning purposes.
deleted 7mo ago
[deleted]

slopinthebag 7mo ago

Swift truly is one of the languages of all time. I started a mobile app with the UI built in Swift and the core in Rust. The amount of implicit and hidden behaviour, magical fields being generated on objects because of certain annotations, the massive amount of @decorators...it's too much. I'm going to have an LLM generate the SwiftUI and touch as little of it as possible. It's also strange because before I learned Swift, I heard about how beautiful it is but I find it much noisier than Rust.

qn9n 7mo ago
I find rust much noisier, especially at its basics where you write “for item in items” instead of using iter()
- slopinthebag 7mo ago
  Idk, I don't swift is objectively noisy but there is something about reading it that just hurts my brain. Stuff like ForEach(vm.sorted(by: \.name)) { user in row(for: user) } \. looks like a syntax error to me, wtf. Also, "in" instead of -> ??? .padding(.vertical, 4) I also really dislike how you can leave off the type name, meaning you never actually know what that Type is unless you literally inspect the signature of the caller. func sorted(by keyPath: KeyPath<User, String>) -> [User] { users.sorted { $0[keyPath: keyPath] < $1[keyPath: keyPath] } } ??? Yeah I fully accept it's just a me problem. But I hate it haha.
ChadNauseam 7mo ago
What are you using for rust-swift interop?
- slopinthebag 7mo ago
  uniffi
trevor-e 7mo ago
>I heard about how beautiful it is This used to be the case around Swift 4, but since then they've added so many features and keywords to the language. Now the simplicity and elegance is gone. Also it seems like there was a marked change in the culture of Swift. It somehow attracted a lot of the "ackchyually" crowd which resulted in a lot of massively complicated features. I liked to occasionally browse the evolution docs and they got more and more complex over time.

mikusnuz 7mo ago

The noncopyable types improvements are the most underrated part of this release. Finally makes it practical to model unique ownership in Swift without fighting the compiler.

gigatexal 7mo ago

My chances of landing at Apple increased when they launched Swift. I am too dumb to learn objective C but swift I can do.

cdcarter 7mo ago

I spent last week (with Opus, of course) porting the xv6-riscv teaching operating system to a bunch of different languages. Zig, Nim, LISP, and Swift. The improvements in embedded Swift have definitely made it one of the most enjoyable/productive languages to work on the OS. I feel like I can build useful abstractions that wrap raw memory access and make the userland code feel very neat. On the other hand, the compilation times are SO bad, that I'm really focusing on the Nim port anyway.

sspiff 7mo ago
It's been a long time since I came across Nim. I thought it was really interesting about 12 years ago. What made you land on Nim instead of any of the more obvious alternatives?
- cdcarter 7mo ago
  I was looking for something that allows easy access to direct memory, with a syntax thats a little easier to explain than C. Frankly, zig was not actually a real viable option based on that syntax requirement but I still wanted to explore it. Nim really is clean and simple.
  - PKop 7mo ago
    How about Odin?
  - functional_dev 7mo ago
    yeah, Nim is great for that... much easier to explain to others than C or Zig especially for math code
  - flykespice 7mo ago
    Yeah, for a language that claims to be a better modern alternative to C, zig verbose syntax is really an eyesore to look at compared the very same codebase written in C... I lost immediately any interest on it
  - seanw444 7mo ago

jwlake 7mo ago

did they ever add #define? bridging constants from the build system to swift with static NSString * const kConstValue = @XSTR(CONST_VALUE); is soooo annoying.

fingerlocks 7mo ago
Only integers for #defines in C-headers, enabled with a recent-ish compiler flag. Swift has a #define but it’s just an ifdef list of flags assigned to one compiler setting. But you can bridge build setting variables using some clever xcconfig macros that combine both preprocessor systems.

vladde 7mo ago

i worked with SwiftUI for about two years, and i think it's a really nice language. the compiler is very slow though. but i think it's too coupled to Apple still. when i tried getting anything running on non-Apple, i had so much trouble i decided then to not even bother.

wahnfrieden 7mo ago
skip.dev helps

MrTomatoes 7mo ago

Nice update, but it's a shame I can't write on it, not because I don't want to, but because it doesn't support it.

MrTomatoes 7mo ago
but still a good update

w10-1 7mo ago

Beyond the marketing view... here are the (incomplete) changes: https://github.com/swiftlang/swift/blob/main/CHANGELOG.md Here are the evolution proposals that landed in 6.3: https://www.swift.org/swift-evolution/#?search=6.3 Overall 6.3 ended up mostly about integration: stdlib, c/c++ (often driven by swift-java interop needs), and builds. SPM (swift package manager) is slowly reaching out to take over xcode build features (e.g., resources most recently), and they have been inching and hacking their way to a new swift-build engine (now experimental) and "prebuilt" modules for the compiler/IDE macro support. Things Go Wrong all the time when trying to replace parts while driving, and there's very little visibility or control over the interactions between SPM and Xcode. Conversely to integrations, endogenous language progress seems relatively quiet because there's a lot of behind-the-scenes work extending the initial blush of lifetime controls to iterators, stdlib types, etc. (never mind parameter packs). They're in year 4+ of building out the function-coloring of concurrency and isolation domains (6.2 had an "easy" mode that caused lots of problems), so adding year 2+ dataflow coloring of lifetimes is doubly complicating. Naturally, diverse support for exciting new features results in quite a spread in the third-party library ecosystem of support for various language features. And now with AI entrepreneurs rewriting and porting any project that can score hits and kudos, the usual open-source authorities are losing their steam. Finally, there's the baseline platform complexity of multiple OS and devices, physical and simulator debugging support, cloud CI... So: that makes four dimensions of complexity. As a Swift developer you'd have to be very careful to stay on a working path as things shift underneath you. All for the love of it?

jshier 7mo ago
Looks like swift-build will be the default in Swift 6.4: https://forums.swift.org/t/swiftpm-development-update-default-build-system-change/85548/ https://forums.swift.org/t/swiftpm-development-update-defaul... Unfortunately, swift-build is what Xcode has been using for years now, and has major performance issues: https://forums.swift.org/t/target-dependency-graph-computation-performance-too-slow/81552/11 https://forums.swift.org/t/target-dependency-graph-computati... Perhaps using it in both SPM and Xcode will lead to improvements, but I'm not especially optimistic.
- 7mo ago

chrismsimpson 7mo ago

Okay so the module import thing is interesting and feels like 1) it should have been included on day one and 2) might have made Swift more viable for projects like Ladybug