1

I think Swift should really achieve its full capabilities if & only if it start cross-platform compilation just like Go and others, in Swift 6.
Any ideas on cross-platform compilation options?
Secondly, A tweet from Joe Groff

Screenshot_20220804-152724_Twitter
Screenshot_20220804-152724_Twitter720×533 59.2 KB

Why React Native and not something more native like C or C++?

5 Likes
2

I would not recommend taking Joe's Twitter feed as an official indication of the direction of the Swift language/compiler :slight_smile:

35 Likes
3

Just to make the implicit explicit: Joe is being facetious in that tweet, inviting us to imagine the absurd implications of an absurd idea.

19 Likes
4

The react native part was a joke.

The write once run everywhere mantra will always hunt us.

Here is a good language presentation along similar lines (that I also think applies to swift)

1 Like
5

Joe is an inveterate “shitposter” on his personal Twitter account. He was making a joke about the fact that some popular mobile apps have recently moved to React Native by suggesting that the Swift compiler was going to undergo a similar shift—a silly idea since React Native is used primarily to create cross-platform user interfaces, but a compiler does not have a graphical user interface.

In reality, the Swift compiler is currently written in C++ with some non-critical components written in Swift. There has been discussion about implementing more of the compiler in Swift, but no other languages are being considered for implementing the compiler.

19 Likes
6

Thanks for the elaboration. @beccadax

7

So what you trying say is that no cross platform compilation yet :pensive::pensive::sleepy::sleepy: even in Swift 6

8

"write once, run everywhere" was the famous slogan of Java which was not true in practice.

2 Likes
9

The compiler is compiled for macOS, iOS (in Playgrounds), Linux, Windows, BSD, Android, and Haiku, among others I've missed. It is definitely a cross-platform compiler.

It can also be used to cross-compile from one platform to another. It just happens to be written in C++.

8 Likes
10

Swift compiler is by design a cross compiler, as it is one of its most use feature: compiling for iPhone / AppleWatch / AppleTV from macOS.

And by the way, swiftc has a -target parameter.

11

Okay but can you provide me with the swiftc options or documentation something of that sort :thinking:

12

I think some folks work on a tool (I think it’s name is Swifty) that should help with compiling for different platforms. While you can currently compile to target different platforms, you need to be on those platforms. This is less noticeable in Apple platforms since the SDK of all OS’s are accessible to the compiler. You can’t, however, at least to my knowledge, target Linux from a macOS compilation. The problem is that macOS doesn’t have the necessary SDK’s used by components as basic as the standard library. So while you might be able to generate the machine code for x86 or arm you can’t really make system calls. I’m not sure exactly what folks are working on, but people are aware of this problem.

13

I had some good results using GitHub - CSCIX65G/SwiftCrossCompilers: SPM toolchain to cross compile Raspberry Pi (arm64) and Amd64 Swift binaries on macOS

5 Likes
14

Nice one there :clap:

15

Why React Native and not something more native like C or C++?

What could be more native than React Native? Maybe if they come out with C++ Native in the future we could consider using that instead of React Native, but until someone comes up with another toolchain with the word "native" in it I think our best bet is to use React Native going forward

5 Likes
16

As far as I know, I didn't see available Swift toolchain on FreeBSD or other *nix systems outside of Linux and macOS. At this point, Swift's cross-platform isn't comparable to Rust.

17

FreeBSD is one of the platforms that received an early port and @3405691582 has been working diligently on the OpenBSD port. There was some work towards a Haiku port as well.

18

Just some thoughts: I think there is a difference between „supported by swift.org“ (i.e. listed on the download page) and „runnable in principle on system soandso“ (e.g. RedHat I think). The second might be interesting and nice, but being able to say „it is supported“ is an important thing. Maybe this is a misconception (is it really necessary to be „supported by swift.org“, or what would this really mean?), but then how to address this misconception, or how giving people a way to judge if it is „quite safe“ to use Swift on a certain system? Compare this to Rust: There the answer is also not that easy, but at least they try to give a helpful answer…

19

It seems like Swift really only has two tiers that roughly correspond to Rust's Tier 1 and 2, and Rust's Tier 3. Really, they are: Swift ships officially for the platform and there are guarantees it will build and ship for those platforms, and the community supports this platform (with various guarantees of support, from community CI to only periodically checking to see if it builds on the platform) or Swift exists for the platform and is shipped by platform vendors/packages/ports systems available.

That first tier I would say are the platforms listed on the Downloads page; the second tier is a little more nebulous. We could do a better job of documenting that second tier, I suppose, but it depends if you're approaching Swift from someone who is comfortable downloading the source and building it versus if you're just looking for a software package to install...

1 Like
20

This works well for Droid.

We cross compile from our Apple silicon MacBook Pro, and it works great.
Very large swift & c++ codebase using swift package manager for builds, > 100mb binaries., so it passes the sniff test.

3 Likes