Live data from Hacker News

Swift on Windows

swift.org

161–170 of 209 posts

Re: Swift on Windows

#161
post #35

Earlier quoted context omitted.

Yeah it just reached alpha. I’m using Kotlin to power a side project on iOS with a SwiftUI view layer. I’ve yet to actually implement the Android version though.

We’re looking to rewrite a legacy C++ shared component that had become unmaintainable and are considering Kotlin native, mostly because it will be easier to hire for a mobile component written in one of the four primary mobile languages. How is your experience using it on iOS?

Overall really good, I picked it up pre alpha and haven’t needed to change that part of the codebase too much since then so can’t tell you how much has improved, it was stable enough for me even then. It’s extremely flexible and doesn’t require you to buy in completely, I’d recommend trying out a small framework first to see how it could work for your team. It suffers from the various early adopter type issues, not many third party packages etc but the jet brains docs and tutorials are pretty good, compile time also isn’t the fastest yet but they’re working on it. Kotlin’s async model can tale a bit to wrap your head around if you’re new to it too. Interfacing with the host platform is also pretty painless compared to the react native or flutter process.

Re: Swift on Windows

#162

Earlier quoted context omitted.

WinForms is just a wrapper around Win32 API - which is closed, and so won't run on other platforms. So in many ways very similar to Apple's position on Swift and SwiftUI

Yes, but even-so it's now far easier to make an alternative WinForms implementation for non-Windows platforms. Mono had their own workable WinForms implementation a while ago (which was a clean-room implementation, IIRC), but now that isn't necessary. WPF, unlike WinForms, is ostensibly fully separate from Win32 and so should be possible to port it to non-Windows platforms.

Mono reimplemented WinForms from scratch, and any port of WPF would also have to be a from scratch reimplementation. Same for SwiftUI.

Re: Swift on Windows

#163
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?

Re: Swift on Windows

#164
post #86

Earlier quoted context omitted.

Sounds a bit like developing in Haxe: https://haxe.org

Haxe seems to have no Swift or Kotlin support :( I'd be curious to know why that is, given that once you have a few languages working, adding more on, intuitively (I have no experience in this) wouldn't be too difficult, given how many features the languages share?

Sort of. I can't comment on Kotlin, but Swift is a different beast though. Swift's generics are very different from say c#, java or even c++ templates, especially when you mix them with protocol associated types, which are also sort of, but not exactly generics.

In Elements we spent a lot of time on getting it right, and I think we have most edge cases covered for user code. The way generics are used in the Swift runtime library seems impossible to map perfectly on top of the concept of generics as C# has them though.

Re: Swift on Windows

#165

Earlier quoted context omitted.

Sure, I guess if they feel the open source versions of Swift's standard library are functional enough to release production quality software. Keep in mind, the UI code will be completely custom for Windows though.

> the UI code will be completely custom for Windows though So Swift programs on Windows will actually look and feel like a Windows program? Good.

Sorry to disappoint but :

> After an extensive discussion, we ended up with Electron as the front-end part of future Spark for Windows.

Apparently they use a Swift plugin for Nodejs

Re: Swift on Windows

#166
post #20

Earlier quoted context omitted.

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. [0] - https://docs.microsoft.com/en-us/windows/apps/desktop/

For a language compiling to native instructions, there's really only the C(++) API. UWP is barely used in my experience and WPF/Windows Forms are basically exclusive to the dotnet framework. Windows Forms and the native API share most of their controls' look and feel while WPF is a free-form application framework that allows you to ignore all UI standards if you desire to. I can't remember the last time I've seen a W…

UWP is so last year! We're all about WinUI now! ;)

Re: Swift on Windows

#167
post #162

Earlier quoted context omitted.

Yes, but even-so it's now far easier to make an alternative WinForms implementation for non-Windows platforms. Mono had their own workable WinForms implementation a while ago (which was a clean-room implementation, IIRC), but now that isn't necessary. WPF, unlike WinForms, is ostensibly fully separate from Win32 and so should be possible to port it to non-Windows platforms.

Mono reimplemented WinForms from scratch, and any port of WPF would also have to be a from scratch reimplementation. Same for SwiftUI.

But they don't need to reimplement it entirely from scratch or as a clean-room implementation because:

1. WPF is now MIT-licensed.

2. Unlike WinForms, the bulk of WPF is managed-code, not a thin-wrapper over Win32.

Therefore anyone can now port WPF to Linux, macOS, etc - and they only need to port the "PresentationCore" part of WPF (i.e. the native parts that expose Direct3D drawing surfaces to WPF).

Re: Swift on Windows

#168

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…

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

Congratulations, you've invented the JVM.

Re: Swift on Windows

#169
post #54

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…

> I'm not entirely sure what the point of this effort is for?! I'm not quite sure I understand your point. Are you saying Swift has no value outside of SwiftUI? It's a pretty nice general purpose language.

[deleted]

Re: Swift on Windows

#170

Earlier quoted context omitted.

this is actually a community project, the guy behind all this (Saleem) isnt even at Apple, hes at Google.

Is it just a hobby project, or actually sponsored by Google? They are trying to push Swift for Tensorflow [1], so proper upstream cross-platform capability would probably be important to them. [1] https://www.tensorflow.org/swift

It's pretty clear that since Chris Lattner left Google the Swift Tensorflow version isn't really going anywhere.
Post reply on HN