Live data from Hacker News

Swift on Windows

swift.org

151–160 of 209 posts

Re: Swift on Windows

#151

Earlier quoted context omitted.

I think pjmlp is saying that Apple should be the one to improve the debugger and to improve the Windows support in the Swift Package Manager, rather than soliciting contributions.

What I was trying to say is why should Apple port Swift to Windows? They have to prioritize resources and Windows should be way down near the bottom of the list. It’s easy to say Apple has nearly infinite amounts of resources, but that never true in the software business. Someone has to manage the project, hire/manage teams, make decisions on goals, objectives, and they have to be managed by someone in engineering le…

> They have to prioritize resources

Hence pjmlp wrote: "Poor Apple, budget cuts have been hit really hard". I think that's entirely fair.

Apple's resource is not infinite, but it's certainly more than enough to port Swift to Windows. Hence pjmlp says it shows "how important this is to Apple", especially in comparison to Java (Oracle) or .NET (Microsoft). I tend to agree.

Re: Swift on Windows

#152
post #14
post #6

Swift for Android would be a real milestone. There are not so many mainstream cross mobile development platforms.

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

[deleted]

Re: Swift on Windows

#153
post #35
post #14

Earlier quoted context omitted.

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

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?

Re: Swift on Windows

#154

Earlier quoted context omitted.

I think pjmlp is saying that Apple should be the one to improve the debugger and to improve the Windows support in the Swift Package Manager, rather than soliciting contributions.

And yet they didn't solicit anything. Posts on the Swift forums show that Saleem, known as compnerd, took on the task of porting to Windows himself, completely unprovoked — when he began to have something to show, the Swift developer community began to rally around him. That's how open source is supposed to work, isn't it? Somebody wants a thing, they develop it, release it, and everybody improves on it?

Meanwhile on Java and .NET world, it is Microsoft, Oracle, IBM, Azul, Linaro,.... putting the bulk of work.

Re: Swift on Windows

#155

Earlier quoted context omitted.

Or more likely because Rust was developed to support Windows 7 before it was deprecated; Swift never targeted Windows 7. Swift was open sourced in 2015, the year when Windows 7's mainstream support ended; at that time, Swift only targeted Mac OS X and Ubuntu. Rust began as a project in 2010, Windows 7 was released in 2009.

I think GP's comment is fair. The portability of Rust is of a completely different order of magnitude than Swift. I mean, people have actually gotten it running on Windows 98 SE. And on Windows, Rust has access to a rich winapi surface, nice COM wrappers (including semi-official support through Microsoft's com-rs), a WinRT projection. Not to mention that crates basically just work. Maybe it isn't a first-class suppor…

This Rust/WinRT translation is the key for Windows maturity now. C translation is the everywhere basic but Windows support is achieved with eh WinRT translation.

And right now, that is C++, JS, Rust and .NET. Not more not less.

Re: Swift on Windows

#156

Earlier quoted context omitted.

> 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?! SwiftUI is just a closed source framework. What's so confusing here? We don't expect Microsoft to develop its proprietary APIs out in the open despite it having a large presence in the open source world, why would…

> We don't expect Microsoft to develop its proprietary APIs out in the open despite it having a large presence in the open source world, why would we of Apple? .NET is fully open-source now and it is developed in the open. And not just the BCL, but also platform UI/UX libraries like [WinForms]( https://github.com/dotnet/winforms ) and WPF. (Yeah I was taken aback too: if you told myself from 10-15 years ago that WinF…

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

Re: Swift on Windows

#158
post #154

Earlier quoted context omitted.

And yet they didn't solicit anything. Posts on the Swift forums show that Saleem, known as compnerd, took on the task of porting to Windows himself, completely unprovoked — when he began to have something to show, the Swift developer community began to rally around him. That's how open source is supposed to work, isn't it? Somebody wants a thing, they develop it, release it, and everybody improves on it?

Meanwhile on Java and .NET world, it is Microsoft, Oracle, IBM, Azul, Linaro,.... putting the bulk of work.

And thus dictated by their whims only, instead of shepherding and encouraging outside perspectives

Re: Swift on Windows

#159

Earlier quoted context omitted.

> We don't expect Microsoft to develop its proprietary APIs out in the open despite it having a large presence in the open source world, why would we of Apple? .NET is fully open-source now and it is developed in the open. And not just the BCL, but also platform UI/UX libraries like [WinForms]( https://github.com/dotnet/winforms ) and WPF. (Yeah I was taken aback too: if you told myself from 10-15 years ago that WinF…

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.

Re: Swift on Windows

#160
post #30

Earlier quoted context omitted.

It has run on windows for years. It's fairly limited in terms of distro support, but this is a stated goal for Swift 6.

Presumably "windows" was a typo, and you meant Linux instead, but to be clear, official support for Swift on native (ie. not WSL) Windows is new in this release, and is largely the work of Saleem Abdulrasool who wrote the linked blog post.

Yes I did mean linux, thanks for the correction
Post reply on HN