Swift Blog

Toady I used GLM 4.7 to port a C++ project of mine to Rust, so I could read and toy with it, to get into the language: https://codeberg.org/RickStanley/agatetepe-rs.

Really interesting results, not sure how well it is written but works. I was quite found of Rust syntax; it certainly is not as convoluted as C++ (in my opinion).

Then I read this article. Since I was already eye-balling Swift for some time, I decided to give it a try and port to it, using Rust implementation as reference, and this time, without much of A. I. assistance, if I could help it.

I'm using an qcow2 Debian trixie arm image in UTM as playground. I found out that there is no packaging for Debian at the time of this writing: https://github.com/swiftlang/swift/issues/60690. No problem! They have a script for installing: https://www.swift.org/install/linux/

curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \
tar zxf swiftly-$(uname -m).tar.gz && \
./swiftly init --quiet-shell-followup && \
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" && \
hash -r

But, god damn, the size is huge,

Unsupported Linux platform
Debian GNU/Linux 13 (trixie) is not an officially supported platform, but the toolchains for another platform may still work on it.
Please select the platform to use for toolchain downloads:

0) Cancel
1) Ubuntu 24.04
2) Ubuntu 22.04
3) Ubuntu 20.04
4) Ubuntu 18.04
5) Fedora Linux 39
6) RHEL 9
…

How would C track references for heap-allocated data originating from (A)RC-based language?

I don't think what you say on .NET correlates with reality - you are not supposed to pass managed objects across FFI (you just can't, it won't let you unless you do unsafe cast shenanigans) - the correct way is to either marshal the data or use blittable representation (plain structs can be passed as is, either by reference or value, same goes for arrays/pointers of primitives). On the rare occasion where unmanaged code needs to keep a GC object alive, it is passed via special GCHandle but that's an exception not the rule.

Swift has its own high level representation for such objects which are very much not FFI compatible. ARC in Swift is a feature that requires compiler involvement to work correctly, and its structs are not FFI compatible unless they are "trivial". Swift also has its own more advanced Swift Library Evolution ABI, which is strictly not C ABI you expect out of your regular library and has its own calling convention and semantics.

Overall, there seem to be strange misconceptions about how these languages work so it would be best to check with the documentation first:

.NET P/Invoke (FFI):

- https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke

- https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/interop#linking

Swift non-C ABI:

- https://github.com/apple/swift/blob/main/docs/LibraryEvolution.rst

-…

On my iPad, without scrolling, the screen shows almost nothing, just a download button and some text that, I think users will ignore. I think that’s a waste of valuable screen estate.

Also, apart from a quote from David Heinemeier Hansson the home page doesn’t even mention that ruby is a programming language.

For comparison, the following all mention that above the fold, with a short phrase indicating what you would want to use the language.

- https://www.python.org/ has “Python is a programming language that lets you work quickly and integrate systems more effectively. Learn More”

- https://www.perl.org/ has “Perl is a highly capable, feature-rich programming language with over 37 years of development”

- https://www.php.net/ has “A popular general-purpose scripting language that is especially suited to web development. Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world.”

- https://www.swift.org/ has “Swift is the powerful, flexible, multiplatform programming language. Fast. Expressive. Safe.”

> Let's say i want to expose an async call to a local sqlite instance on android.

I don’t know, I don’t do android dev. I just made sure my library was running on it then moved on. I know Swift is working on having bidirectional interoperability with Java[1], so I guess when they do it’ll just work? But I did not dig more on the subject.

Regarding the size I’m not sure as I never compiled a binary that is actually useful. I make sure everything runs, but as I’m building a library this goes to building the tests then running them on WASI and that’s it.

Regarding the Swift toolchain version, using swiftly[2] is recommended nowadays if you don’t need Xcode. Using the default toolchain provided by Xcode usually brings trouble when using SDKs. Using swiftly you’ll get the same experience as on Linux basically. (This will probably change, but it is like so currently.)

[1] https://github.com/swiftlang/swift-java

[2] https://www.swift.org/install/macos/#:~:text=Swiftly

Great writeup, and I love that the authors looked at a lot of other languages. The solution section on how to prevent races is a bit light still - I‘m curious how they will solve this.

I think there will need to be exceptions to a strict race-free model eto not take away from dart‘s current capabilities, and without forcing people into something like a borrow checker. Swift has `@unchecked Sendable` which lets you tell the compiler "I promise I'll take care myself to keep everything in there race-free".

What I‘ve been missing in Swift are tools that let me add safety _within_ such @unchecked Sendables. There's the Swift Atomics lib: https://www.swift.org/blog/swift-atomics/, but its quite limited in its capabilities. So for now, I find myself reaching for tools provided by the community, like pointfree's LockIsolated: https://github.com/pointfreeco/swift-concurrency-extras/blob/main/Sources/ConcurrencyExtras/LockIsolated.swift.

That's probably the view of Apple execs, but it is not the rhetoric that comes out of the Swift Org itself:

https://www.swift.org/
> a programming language to empower everyone to turn their ideas into apps on any platform.

https://www.swift.org/about/
> the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services

> a web-based REPL can when working with Linux server-side code

> it is now free to be ported across a wide range of platforms, devices, and use cases. Our goal is to provide source compatibility for Swift across all platforms ... extend the cross-platform capabilities of Swift ... source compatibility for Swift code across all platforms ...

> Open-source Swift can be used on Linux to build Swift libraries and applications

> We’d love your help to bring Swift to even more computing platforms.