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

131–140 of 209 posts

Re: Swift on Windows

#131

Post by BoorishBears »

anoncareer0212 wrote: post #123
GeekyBear wrote: post #115

Earlier quoted context omitted.

>Play Services is a closed source app owned by Google and licensed as part of the Google Apps package. Any feature you see move from "normal" Android to Google Play Services is also moving from open source to closed source. This app pulls off the neat trick of not only enticing users with exclusive, closed source features, but locking in third-party developers with Google's proprietary APIs as well. https://arstechni…

Yeah, the language you quoted is histrionical and responsible for innumerable mistaken impressions, including me, until last year. If you skim the headings you'll see it's things that'd more or less be 'obviously' proprietary - headings include Google Maps API, in app purchases, Play Games saving/scores...

As someone who's spent just as much time (if not more) developing for embedded Android devices without Google Play Services as developing for "traditional" ones, you're making a meaningless distinction.

It's half the functionality that makes an Android device work for an unsophisticated user. To the point that people have to write shims just to get basic apps to run without it.

And the amount of functionality Google has moved into GPS has only grown over the years mind you, from things like Doze and its interaction with GPS, to installation processes that hook into it for verification...

If Android didn't have Google Play Services, it wouldn't be anything more than what Linux on smartphones is... a toy for geeks, nothing competitive with offerings like the iPhone.

Re: Swift on Windows

#132

Post by ifmpx »

zapzupnz wrote: post #126
zerr wrote: post #74

The toolchain requires Win10 - but can a resulting executable be deployed on Win7?

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!

Not to turn this into a contest but Rust officially supports windows 7. In fact I believe Rust fully supported windows XP too until very recently when they decreased platform support to supported-but-unbuilt-and-untested.

Another benefit of a community-driven language as aposed to a corporate-controlled one.

Re: Swift on Windows

#133

Post by zapzupnz »

ifmpx wrote: post #132
zapzupnz wrote: post #126

Earlier quoted context omitted.

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!

Not to turn this into a contest but Rust officially supports windows 7. In fact I believe Rust fully supported windows XP too until very recently when they decreased platform support to supported-but-unbuilt-and-untested. Another benefit of a community-driven language as aposed to a corporate-controlled one.

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.

Re: Swift on Windows

#134

Post by DaiPlusPlus »

zapzupnz wrote: post #121
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, 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 WinForms would be open-sourced under the MIT license I'd think you were mad - or that Microsoft went out of business after the Year of the Linux Desktop really happened and open-sourcing everything was their swansong).

Re: Swift on Windows

#135

Post by saagarjha »

simonh wrote: post #66
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…

Why would Apple want to write a completely new cross platform UI library, cloning the Mac OS desktop UI and give it away, or give away the Mac UI directly? How does that serve their interests? The main purpose seems to be to enable developing back end server code in the same language and using the same service APIs as the client code on mobile and desktop.

SwiftUI is designed such that a port to another platform would not be as awful as a clone of the Mac UI.

Re: Swift on Windows

#136

Post by raphlinus »

zapzupnz wrote: post #133
ifmpx wrote: post #132

Earlier quoted context omitted.

Not to turn this into a contest but Rust officially supports windows 7. In fact I believe Rust fully supported windows XP too until very recently when they decreased platform support to supported-but-unbuilt-and-untested. Another benefit of a community-driven language as aposed to a corporate-controlled one.

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 supported language for Windows just yet, but it's starting to feel pretty close.

Re: Swift on Windows

#137

Post by saagarjha »

zapzupnz wrote: post #129
armadsen wrote: post #93

Earlier quoted context omitted.

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…

> I'm not so sure convincing developers was the reason for that, though. It was for Finder. During one of the WWDCs or MacWorlds (I don't recall which), Jobs specifically mentioned that Finder was written in Carbon as a way to show that Apple eats its own dog food. It was the big demonstration that Carbon wasn't some second-rate API … although, of course, it was. Dogfooding as a concept isn't Apple-specific but it's…

And then they had a big thing where they rewrote it in Cocoa, too, to show how easy it was to migrate over.

Re: Swift on Windows

#138

Post by raphlinus »

saagarjha wrote: post #135
simonh wrote: post #66

Earlier quoted context omitted.

Why would Apple want to write a completely new cross platform UI library, cloning the Mac OS desktop UI and give it away, or give away the Mac UI directly? How does that serve their interests? The main purpose seems to be to enable developing back end server code in the same language and using the same service APIs as the client code on mobile and desktop.

SwiftUI is designed such that a port to another platform would not be as awful as a clone of the Mac UI.

I speculated when it first came out that internally they have a port for either Windows or Android or both, if for no other reason than to discover any architectural limitations that would preclude such a thing. But I also think it's very unlikely that SwiftUI will ever be released for any non-Apple platforms.

Re: Swift on Windows

#139

Post by saagarjha »

chin7an wrote: post #20
thought_alarm wrote: post #17

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

On macOS there’s three: Cocoa, Catalyst and SwiftUI.
Post reply on HN