Swift has this weird sort of ecosystem where Apple builds much of the platform in a very secret (most of the roadmap isn't shared), closed-source variant for its own OS. Then it has this open source version, with a very public compiler (roadmap IS shared) that allows cross platform toolchains like this one to exist.
I call it out as weird because take SwiftUI for example, the main excuse Apple engineers gave for why SwiftUI itself is closed-source is because a lot of important code lives inside of UIKit/AppKit. Huh?! Apple being Apple, each revision of SwiftUI is now glued to a singular release of a major revision of the OS. Instead, if Apple decided to built SwiftUI entirely in the open, then the foundational APIs that are closed-source would have to co-exist with the open source versions in order to work.
This is in contrast to Rust, another LLVM language ported to Windows. Every part of Rust is open source and is built to work with open roadmaps and very thoroughly documented standard libraries.
So on the one hand, if you're a fan of Swift, you have yourself a nice hobby language you can play with on the weekend on your gaming PC. On the other, I'm not entirely sure what the point of this effort is for?!
Slightly OT: I wish people wouldn’t put such large license headers in source code. I just don’t see the point, and it’s often longer than the actual source!
I haven't done Windows development in over 10 years, but I really wasn't expecting to see what appears to be a stripped down implementation of AppKit wrapped around the old Win32 APIs, like it's 1999. (Nor Hungarian Notation).
I thought WPF or WinRT or UWP was supposed to have replaced Win32 by now.
I don't do any desktop development or use Windows much for that matter, but it looks like as of today, there are at least 4 ways [0] to build Windows desktop apps. No wonder the UX feels far less consistent and enjoyable than macOS.
I really like Swift. Recently I've been using it as my "main" language in developing a macOS user interface for my MSc research project, and it has literally made developing fun!
Great to see it getting more support outside of the Apple domain.
I wrote some swift maybe 4 or 5 years ago when I was doing mobile app stuff and had access to a Mac. I remember finding the language pretty enjoyable, but considered its xplat potential questionable. At the time, I believe it did run on linux and people were touting it as a solid platform for building server side applications. I dont think that was ever realized though.
This is really cool. I have been watching Swift with interest mainly because it is an answer to the question: How would a bunch of C++ experts (for example Doug Gregor and David Abrahams) design a language if they could do it all over again?
Before, the lack of a good cross-platform story kept me away. Now, I think this gives me an excuse to play around with Swift.
To abuse an old meme: "...yes, but does it run on Linux..."
It seems like Windows already has a glut of similar tools; if you wanted to make a real impact with a fairly new language, which Swift is, with massive corporate backing, which Swift has, the one would think Linux would be a far more opportune destination for an effort like this.
Swift alone would be nice, but implementations of UIKit and/or SwiftUI for Android would be even better. SwiftUI in particular makes a lot of sense as a cross-platform UI framework, since its appearance and behavior adapts to the platform it's running on instead of trying to shoehorn in a single look and feel everywhere.
I think Kotlin is ahead enough in this area that it'll win. Plus it's much easier to compile Kotlin to native and use that from Swift than to use native from Java/Kotlin
Readdle apparently built spark (their client mail app) using a single swift core module compiled to all platforms, including android.
They released a custom swift toolchain to target android.
Unfortunately there doesn’t seem to be a lot of interest from the swift core team, because i couldn’t find any official info on the state of android compilation (what part of the stdlib works, what doesn’t, and how to interop from java /kotlin to something compiled with swift).
I was working on a server-side project written in Swift (not my language choice) for 2 years before switching to my current company where I mostly write Kotlin.
There are some aspects where Swift is nicer in theory (e.g. Swift enums beat Kotlin sealed classes in terms of ergonomics and, while unnecessary for 99% of projects, we had some genuine use case for custom operators, working on a maths product). But other than those, it seems to be that Kotlin is the superior language in almost every respect. It seems to have none of the major flaws that Swift has, and the tooling is great, which is the exact opposite of my experience with Swift.
It's great to see more languages supported across more operating systems, though outside of iOS app development I am exceedingly dubious of the usefulness of Swift.
so swift is going cross platform, what would be the final size of executable and how much ram would it take to run as compared to electron? Can we say there's a slight possibility that devs would prefer swift over electron for desktop apps?
I'd be surprised if it could. Mainstream support for Windows 7 ended years ago, extended support ended this year. If the Swift community (or more accurately, the one guy in charge of the Windows port) bothers to support executables running on a deprecated version of Windows, that would come as a mighty surprise to me.
Still, you never know, it might manage to do it by fluke!
I have been using Swift for a month, so I am a beginner. It has some modern features, but it is lacking any real sense of community and feels very incomplete. Its threading and IPC models are clunky and its network code makes XMLHttp
Moving from Linux to Apple development has been a shock: All the gate keeping to keep me out of their hardware - after a month I still cannot reliably put my code on iOS - not for technical reasons but for license reasons.
Swift really suffers for coming from this environment. IMO leave it alone unless you have to develop for Apple hardware - and if you have to develop for Apple hardware - that is a business problem and you need to solve it.
It seems that there is some "community" of people not employed by Apple around the development of Swift.
And it seems that they believe that the "outside" world cares about what is inside Apple's walled garden.
Truth is, for non-Apple people: Swift => Apple => no thanks. It is easier to see an Apple programmer excited about .Net than a Windows programmer paying attention to Swift.
I'm more interested in a compiler that takes any of these languages (C#, Kotlin, Swift) that do the same thing slightly differently, converts them into a lowest common denominator language that can then compile into any target I choose.
For example write code in Swift, compile to X, compile to Kotlin. Voila, I have cross platform code, just need to write some cross platform libraries that wrap UI, networking, etc for each platform.
Elements compiler [0] seems to do just that. Does anyone have experience using it in production? Why is this not being adopted as a viable cross platform solution?
> I'm more interested in a compiler that takes any of these languages (C#, Kotlin, Swift) that do the same thing slightly differently, converts them into a lowest common denominator language that can then compile into any target I choose.
For JVM and .NET/CLR based languages this is pretty easy and common.
> just need to write some cross platform libraries that wrap UI, networking, etc for each platform.
I have the impression that « finding cross platform librairies » for every types of I/O is actually a very very painful step, judging by the time it takes to get the swift stdlib work across all platform.
The « low level language » is actually LLVM intermediate language, and LLVM already support building for all the major targets.
[+] [-] jarjoura|5 years ago|reply
I call it out as weird because take SwiftUI for example, the main excuse Apple engineers gave for why SwiftUI itself is closed-source is because a lot of important code lives inside of UIKit/AppKit. Huh?! Apple being Apple, each revision of SwiftUI is now glued to a singular release of a major revision of the OS. Instead, if Apple decided to built SwiftUI entirely in the open, then the foundational APIs that are closed-source would have to co-exist with the open source versions in order to work.
This is in contrast to Rust, another LLVM language ported to Windows. Every part of Rust is open source and is built to work with open roadmaps and very thoroughly documented standard libraries.
So on the one hand, if you're a fan of Swift, you have yourself a nice hobby language you can play with on the weekend on your gaming PC. On the other, I'm not entirely sure what the point of this effort is for?!
[+] [-] rudedogg|5 years ago|reply
Slightly OT: I wish people wouldn’t put such large license headers in source code. I just don’t see the point, and it’s often longer than the actual source!
[+] [-] geraldcombs|5 years ago|reply
There's an ongoing effort to fix this:
https://www.linuxfoundation.org/blog/2018/08/solving-license...
[+] [-] zerr|5 years ago|reply
[+] [-] thought_alarm|5 years ago|reply
I thought WPF or WinRT or UWP was supposed to have replaced Win32 by now.
[+] [-] chin7an|5 years ago|reply
[0] - https://docs.microsoft.com/en-us/windows/apps/desktop/
[+] [-] tomc1985|5 years ago|reply
[+] [-] xfer|5 years ago|reply
[+] [-] ryanmarsh|5 years ago|reply
[+] [-] oseph|5 years ago|reply
Great to see it getting more support outside of the Apple domain.
[+] [-] non-entity|5 years ago|reply
[+] [-] RcouF1uZ4gsC|5 years ago|reply
Before, the lack of a good cross-platform story kept me away. Now, I think this gives me an excuse to play around with Swift.
[+] [-] melling|5 years ago|reply
https://github.com/melling/SwiftCookBook
[+] [-] jabofh|5 years ago|reply
It seems like Windows already has a glut of similar tools; if you wanted to make a real impact with a fairly new language, which Swift is, with massive corporate backing, which Swift has, the one would think Linux would be a far more opportune destination for an effort like this.
[+] [-] Gys|5 years ago|reply
[+] [-] kitsunesoba|5 years ago|reply
[+] [-] wasyl|5 years ago|reply
[+] [-] bsaul|5 years ago|reply
They released a custom swift toolchain to target android.
Unfortunately there doesn’t seem to be a lot of interest from the swift core team, because i couldn’t find any official info on the state of android compilation (what part of the stdlib works, what doesn’t, and how to interop from java /kotlin to something compiled with swift).
[+] [-] EvilEy3|5 years ago|reply
[+] [-] JamesSwift|5 years ago|reply
[+] [-] Can_Not|5 years ago|reply
[+] [-] pjmlp|5 years ago|reply
[+] [-] longstation|5 years ago|reply
[+] [-] Tainnor|5 years ago|reply
There are some aspects where Swift is nicer in theory (e.g. Swift enums beat Kotlin sealed classes in terms of ergonomics and, while unnecessary for 99% of projects, we had some genuine use case for custom operators, working on a maths product). But other than those, it seems to be that Kotlin is the superior language in almost every respect. It seems to have none of the major flaws that Swift has, and the tooling is great, which is the exact opposite of my experience with Swift.
[+] [-] ww520|5 years ago|reply
[+] [-] baumatron|5 years ago|reply
[+] [-] olliej|5 years ago|reply
[+] [-] jerrygoyal|5 years ago|reply
[+] [-] zerr|5 years ago|reply
[+] [-] zapzupnz|5 years ago|reply
Still, you never know, it might manage to do it by fluke!
[+] [-] wdb|5 years ago|reply
[+] [-] leonjza|5 years ago|reply
[+] [-] saagarjha|5 years ago|reply
[+] [-] worik|5 years ago|reply
[+] [-] worik|5 years ago|reply
Moving from Linux to Apple development has been a shock: All the gate keeping to keep me out of their hardware - after a month I still cannot reliably put my code on iOS - not for technical reasons but for license reasons.
Swift really suffers for coming from this environment. IMO leave it alone unless you have to develop for Apple hardware - and if you have to develop for Apple hardware - that is a business problem and you need to solve it.
[+] [-] sedatk|5 years ago|reply
[+] [-] atarian|5 years ago|reply
[+] [-] diego_moita|5 years ago|reply
And it seems that they believe that the "outside" world cares about what is inside Apple's walled garden.
Truth is, for non-Apple people: Swift => Apple => no thanks. It is easier to see an Apple programmer excited about .Net than a Windows programmer paying attention to Swift.
[+] [-] mastrsushi|5 years ago|reply
[+] [-] syspec|5 years ago|reply
[+] [-] alexashka|5 years ago|reply
For example write code in Swift, compile to X, compile to Kotlin. Voila, I have cross platform code, just need to write some cross platform libraries that wrap UI, networking, etc for each platform.
Elements compiler [0] seems to do just that. Does anyone have experience using it in production? Why is this not being adopted as a viable cross platform solution?
[0] https://www.elementscompiler.com/elements/#platforms
[+] [-] nl|5 years ago|reply
For JVM and .NET/CLR based languages this is pretty easy and common.
> just need to write some cross platform libraries that wrap UI, networking, etc for each platform.
Congratulations, you've invented the JVM.
[+] [-] jug|5 years ago|reply
[+] [-] bsaul|5 years ago|reply
The « low level language » is actually LLVM intermediate language, and LLVM already support building for all the major targets.