Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift on Windows

swift.org

Post reply on HN
Print view View original

91–100 of 209 posts

Re: Swift on Windows

#91

Post by alexashka »

jug wrote: post #86
alexashka wrote: post #75

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…

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?

Re: Swift on Windows

#92

Post by kitsunesoba »

jmull wrote: post #72
JamesSwift wrote: post #21

Earlier quoted context omitted.

If thats what you are after then flutter is available today

Flutter doesn't use native controls/frameworks under the hood, so it generally falls into the category of "trying to shoehorn in a single look and feel everywhere".

Yes, precisely. It has a "Cupertino" theme that kind of mimics the iOS look and feel, but it misses the mark and will always be behind the curve a least a release or two in matching the OS.

Re: Swift on Windows

#93

Post by armadsen »

ratww wrote: post #60
chin7an wrote: post #47

Earlier quoted context omitted.

That's interesting, did not know about the carbon to cocoa move, couldn't afford anything Apple back then :) If both platforms had to handle such migrations, I guess it's only fair to say that Windows' solution would be much more difficult given how committed Microsoft is to maintaining backwards compatibility.

Carbon/Cocoa wasn't really a "transition" per se. Cocoa was not only older (the API comes from NextStep), it was also always marketed as being the "Native" API from day one [1]. Carbon was a secondary API marketed by them as a way of having " applications that also run on previous versions of the Mac OS (8.1 or later) " [2]. Carbon apps were uglier, clunkier and harder to write/maintain than Cocoa. Now that I remembe…

Both iTunes and Finder were at least partly Carbon for a long time. I'm not so sure convincing developers was the reason for that, though. iTunes 1.0 was Mac OS 9 only, and didn't even run on Mac OS X. It was a continuation of SoundJam MP, a third-party Mac app that predated the release of Mac OS X. So, really, iTunes was ported forward to Mac OS X using the same process Apple expected developers of existing Classic Mac apps to use, but that probably wasn't a decision (solely) made for developer relations reasons.

I don't know much about the history of Finder in this regard, unfortunately. It of course existed from System 1.0 in 1984, but how much of Mac OS X 10.0's Finder was a complete rewrite and how much was ported from Classic Finder vs NeXTStep is something I have no idea about. It certainly had UX that came from NeXTStep (the column browser, for instance).

Re: Swift on Windows

#94

Post by armadsen »

skohan wrote: post #30
jabofh wrote: post #26

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.

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.

Re: Swift on Windows

#95

Post by donor20 »

jeroenhd wrote: post #88
chin7an wrote: 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…

The push now for UWP is so misguided. I have no clue why they've decided to spend decades making apps jankier and weirder.

Re: Swift on Windows

#96

Post by mpweiher »

jmull wrote: post #67
jarjoura wrote: post #37

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 call it out as weird because take SwiftUI for example Be careful not to confuse Swift with SwiftUI. SwiftUI is just a UI framework. It's the one Apple is pushing right now, but it doesn't really have any bearing on the cross-platform story for Swift. (I doubt it ever will -- I don't think Apple particularly wants to take it outside the Apple ecosystem, and it would be very high effort to do in any case.)

But SwiftUI required some pretty major language changes, which were thus also done in secret and added to the language as a fait-accompli.

Re: Swift on Windows

#97

Post by riquito »

jmull wrote: post #67
jarjoura wrote: post #37

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 call it out as weird because take SwiftUI for example Be careful not to confuse Swift with SwiftUI. SwiftUI is just a UI framework. It's the one Apple is pushing right now, but it doesn't really have any bearing on the cross-platform story for Swift. (I doubt it ever will -- I don't think Apple particularly wants to take it outside the Apple ecosystem, and it would be very high effort to do in any case.)

It looks similar to what happened with dot.net / mono, where Microsoft kept pushing tools and UI libraries for Windows and the ecosystem outside Windows stagnated or played an impossible catch up

Re: Swift on Windows

#98

Post by armadsen »

worik wrote: post #49
worik wrote: post #48

Why?

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 techni…

As part of the Swift community (and the Objective-C and Mac/iOS community for years before that), I disagree that there's no community around Swift. I think the problem is that it's still very Apple platforms focused. If you're an iOS developer, you'll find a big community, and one that has been focused on Swift specifically for the past 6 years (to the point that there are complaints about that, e.g. https://twitter.com/phughes/status/1307024158275112965). There are many conferences every year (well, until this year), plenty of people on Twitter, blogs, multiple community Slack teams, etc. Just in my local area (metro area of ~2 million) we have a 750 person strong, very active Slack team for iOS/Mac/Swift development, and two separate monthly in-person meetup groups (again, before COVID).

If I were a Swift developer focused on Linux or Windows, though, it'd be a whole different story. The author of the linked blog post is a member of the Swift core team, and did most of the work to bring Swift to Windows himself, but outside of him, I don't really know anyone particularly focused on it.

(I've also made a very decent living for 15 years developing almost exclusively for Apple platforms, so I disagree with your last paragraph too, but that's another thing altogether.)

Re: Swift on Windows

#99

Post by thought_alarm »

ratww wrote: post #60
chin7an wrote: post #47

Earlier quoted context omitted.

That's interesting, did not know about the carbon to cocoa move, couldn't afford anything Apple back then :) If both platforms had to handle such migrations, I guess it's only fair to say that Windows' solution would be much more difficult given how committed Microsoft is to maintaining backwards compatibility.

Carbon/Cocoa wasn't really a "transition" per se. Cocoa was not only older (the API comes from NextStep), it was also always marketed as being the "Native" API from day one [1]. Carbon was a secondary API marketed by them as a way of having " applications that also run on previous versions of the Mac OS (8.1 or later) " [2]. Carbon apps were uglier, clunkier and harder to write/maintain than Cocoa. Now that I remembe…

When comparing Carbon and Cocoa, only a fool would choose to write an app in Carbon. But initially there were a few problems:

- On old 90s hardware, Carbon could be faster (due to the C API)

- Apple didn't invent AppKit or Objective-C. That technology was inherited from NeXT and from what I understand there was push-back both within Apple and from the Mac developer community about adopting a language with an unusual syntax that nobody used.

Apple tried to transition Objective-C to a modern C++ style syntax, and failed.

Apple tried to get developers to use Java with AppKit (hence, the name Cocoa) and failed.

Apple tried to get developers to adopt garbage collection, and failed.

In the end, they didn't need to do any of that. Mac developers eventually became quite enthusiastic about Objective-C and AppKit and it quickly because the one true way to write Mac apps.

However, it took many years for Cocoa and AppKit to become fully formed. Up until 2009 and OS X 10.6, there were still many things that couldn't be done in Cocoa and required the Carbon APIs, mostly related to the Mac-specific features of the file system, like persistent file references, icons, metadata, etc.

For example, if you want to implement a UI for copying a file, you're going to want to display a progress bar and have the ability to cancel the operation. Up until OS X 10.6, that simply couldn't be done with Cocoa (NSFileManager, NSURL, etc.). You had to use gnarly Carbon APIs.

(Actually, it still can't be done with NSFileManager, but Apple added that ability to the Darwin file system APIs.)

That's why the Finder was initially implemented in Carbon.

And little bits if Carbon still live on in the modern 64-bit Mac world. If you want to implement global Hot Keys in your app you have to use the Carbon API and convert the Carbon key-codes to their AppKit equivalents.

Re: Swift on Windows

#100

Post by JamesSwift »

kitsunesoba wrote: post #92
jmull wrote: post #72

Earlier quoted context omitted.

Flutter doesn't use native controls/frameworks under the hood, so it generally falls into the category of "trying to shoehorn in a single look and feel everywhere".

Yes, precisely. It has a "Cupertino" theme that kind of mimics the iOS look and feel, but it misses the mark and will always be behind the curve a least a release or two in matching the OS.

OK I misunderstood your ask then. In that case Xamarin.Forms does that today
Post reply on HN