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

51–60 of 209 posts

Re: Swift on Windows

#51

Post by jamil7 »

mrtksn wrote: post #43
non-entity wrote: post #42

Earlier quoted context omitted.

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.

Swift on a server is a think: https://vapor.codes

The docs are very incomplete and common third party dependencies are missing. I know it’s a chicken and egg type situation but vapor is not an appealing option for backend unless you really want/need to use Swift.

Re: Swift on Windows

#54

Post by skohan »

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

Re: Swift on Windows

#55

Post by mrtksn »

jamil7 wrote: post #51
mrtksn wrote: post #43

Earlier quoted context omitted.

Swift on a server is a think: https://vapor.codes

The docs are very incomplete and common third party dependencies are missing. I know it’s a chicken and egg type situation but vapor is not an appealing option for backend unless you really want/need to use Swift.

I was going use it only if there there was an official Firebase support to do things the way they are done on iOS. What I want is to have a server app that communicates with with Firebase services to do certain tasks.

Doing this in Javascript(Node) instead, is very cognitively taxing for me. Mental models are different, so I need to “cool down” and start thinking in the other language when switching between app dev / back end.

Swift is so nice That i would rather do everything in it anyway but not having to switch mental models is the real reason.

Re: Swift on Windows

#56

Post by [deleted] »

skohan wrote: post #54
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'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

#57

Post by atarian »

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 can't think of a good business reason why they would want to open source SwiftUI. If I want to stay on Windows and develop an app using SwiftUI, why would I bother developing for the Mac?

Re: Swift on Windows

#58

Post by jamil7 »

mrtksn wrote: post #55
jamil7 wrote: post #51

Earlier quoted context omitted.

The docs are very incomplete and common third party dependencies are missing. I know it’s a chicken and egg type situation but vapor is not an appealing option for backend unless you really want/need to use Swift.

I was going use it only if there there was an official Firebase support to do things the way they are done on iOS. What I want is to have a server app that communicates with with Firebase services to do certain tasks. Doing this in Javascript(Node) instead, is very cognitively taxing for me. Mental models are different, so I need to “cool down” and start thinking in the other language when switching between app dev /…

I find swift to be the most enjoyable and productive language I’ve used so can relate to you there, for me personally vapor seemed a long way off though. Maybe you could try Go? Kotlin is also very nice.

Re: Swift on Windows

#59

Post by monocasa »

atarian wrote: post #57
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 can't think of a good business reason why they would want to open source SwiftUI. If I want to stay on Windows and develop an app using SwiftUI, why would I bother developing for the Mac?

There's nearly always advantages to being the owner of the complete stack, even if developed in the open and allowing other backends. Making sure that every piece matches your vision without little weird API impedance mismatches for a library being used in many places is a massive win. Nobody expects SwiftUI on Apple to be crippled by a decision, even if it would make SwiftUI on Windows and Linux better.

That's one of the reasons AMD pushed Mantle, then pushed Vulkan and DX12 and dropped Mantle. The shape of the API better fits their model for driver development than OpenGL or DX prior to 11, and they're happy for their competitors to help build an ecosystem that works better on their products than the alternatives at the time.

IMO, this is the best model for library/API development if you can pull it off.

Re: Swift on Windows

#60

Post by ratww »

chin7an wrote: post #47
wvenable wrote: post #31

Earlier quoted context omitted.

Microsoft wanted to take developers in a direction they didn't want to go. They seemed to have realized their mistake and trying to unify this mess. In the recent past, you wouldn't find WPF and Windows Forms mentioned in the same article as UWP. Apple had their own problems with this (Carbon vs Cocoa) but that legacy has been shaken off.

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 remember it: Back in the early 2000s Cocoa was so much better that they had to write iTunes (or was it Finder?) in Carbon to convince developers that Carbon was able to handle real world apps.

The problem with Carbon is that companies like Adobe, Autodesk and Microsoft overstayed their welcome and dragged their feet for almost 10 years instead of porting to Cocoa like Apple recommended in conferences. To convince them to port, Apple deprecated Carbon it in 2007 and removed it 12 years later in 2019.

[1] http://web.archive.org/web/20010617021453/http://developer.a...

[2] http://web.archive.org/web/20010620032754/http://developer.a...

Post reply on HN