Live data from Hacker News

Swift on Windows

swift.org

61–70 of 209 posts

Re: Swift on Windows

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

My point is that Apple's weird choices like SwiftUI being tied to internal versions of the standard libraries creates mixed messaging. It's only general purpose enough that on Mac/iOS you get Apple's version of the standard libraries. On other platforms you use an open source version of the standard libraries as the community sees fit to implement the API.

Bugs in Apple's internal variant are tied to OS releases, whereas bugs in the open source variant are tied to someone getting around to fixing it.

If Apple went all in on open source like Rust, or all in on proprietary/closed, then it would have more consistent messaging about what the language is for.

Re: Swift on Windows

#62
post #51
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 am curious, what did you find missing or unachievable using Vapor?

Re: Swift on Windows

#63
post #54

Earlier quoted context omitted.

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

My point is that Apple's weird choices like SwiftUI being tied to internal versions of the standard libraries creates mixed messaging. It's only general purpose enough that on Mac/iOS you get Apple's version of the standard libraries. On other platforms you use an open source version of the standard libraries as the community sees fit to implement the API. Bugs in Apple's internal variant are tied to OS releases, whe…

In practice I don't think it's that confusing. You have a large standard library which is available everywhere, and then you have a set of proprietary API's which are only available on Apple platforms.

Is the situation that different from C# and windows API's?

Re: Swift on Windows

#64

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…

SwiftUI isn't tied to the OS version.

It has a runtime API that should work with different versions of the OS. There were changes to the compiler that they didn't talk about until after the fact though. After SwiftUI was announced they did run those through swift-evolution.

SwiftUI for the most part is just a runtime library, the compiler changes made things a bit nicer, but most of it could be achieved without compiler changes.

Re: Swift on Windows

#65
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/

I suppose if Swift can only interoperate with C APIs, Win32 would be the only option.

Well, Swift uses LLVM, so it's possible to link it to C++ code with extern "C" declarations.

Re: Swift on Windows

#66

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.

Re: Swift on Windows

#67

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

Re: Swift on Windows

#68
post #48

Why?

It seems that there is some "community" of people not employed by Apple around the development of Swift.

And it seems that they believe that the "outside" world cares about what is inside Apple's walled garden.

Truth is, for non-Apple people: Swift => Apple => no thanks. It is easier to see an Apple programmer excited about .Net than a Windows programmer paying attention to Swift.

Re: Swift on Windows

#69
post #63

Earlier quoted context omitted.

My point is that Apple's weird choices like SwiftUI being tied to internal versions of the standard libraries creates mixed messaging. It's only general purpose enough that on Mac/iOS you get Apple's version of the standard libraries. On other platforms you use an open source version of the standard libraries as the community sees fit to implement the API. Bugs in Apple's internal variant are tied to OS releases, whe…

In practice I don't think it's that confusing. You have a large standard library which is available everywhere, and then you have a set of proprietary API's which are only available on Apple platforms. Is the situation that different from C# and windows API's?

.Net 5 and C# 9.0 are very much 100% open all the way down to the core.

https://github.com/dotnet/roslyn (c#)

https://github.com/dotnet/winforms (UI) https://github.com/dotnet/wpf (UI) https://github.com/dotnet/core (Foundation)

I don't consider the Win32 API itself part of .NET or C# as they've existed long before either.

Re: Swift on Windows

#70

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…

Giving in the end you are comparing, for me at least Rust is more in the family of languages like C++.

Very powerful, fast and close to the metal, but with uglier* syntax and not as productive as the next family of languages. Which are:

Java, C# and Swift (unlike C++ and Rust) for me are pointing into solving a very hot spot of programming, with the balance of power, being more pleasant to program in and feeling more productive.

Your code will be almost as fast as a C++ program, but you dont need to feel (that much) miserable writing stuff into it. (And i say this as someone that likes C++, but knows its not the most productive and pleasant experience)

It remedy some pain points of programming, that in my point of view at least, Rust didnt addressed the same sweet spot as Swift does.

Theres also some good things about Swift right in the corner, that is support to C++ bindings and a more fine-grained control of memory.

Once the memory ownership changes, than we will also be able to consider Swift for the same things as C, C++, Rust and Zig can right now.

Also i would say that dinamic calls while embedding script languages and function builders are very strong points that the language is becoming more powerful with each release.

Also some things like binary stability that Swift have that Rust doesnt are thing to take into account for, giving there are a lot of cases were shipping just the binaries and know they will still work is something very important for projects that cant afford to be open source.

I would consider to use Rust whenever C++ would also fit, but if i can use Swift i would not consider using Rust, because at least for me is a much better language to code.

I think people from the Rust community dont need to fear, because Rust have a strong community right now, and in that particular topic, is Swift that need to catch up and shake up this feeling of being a "apple owned language".

So i dont think they are aiming for the same thing, and therefore they dont need to be compared in a us vs. them basis, giving you can code on both, and i think it could be great if you do it.

Theres a false adage that you need to pick just one language, and having used a lot of languages and platforms over the years, im pretty happy now that i know that such thing doesnt exist.

You are better picking from 2 to 3 languages and use them according the goals of what you are building.

For me, my three languages are: C++, Swift and Python.

C++ for hardcore stuff, Swift for everything that a language like Java or C# could be considered and Python for the more relaxed (and now also expert) stuff.

You can replace Python with Ruby, Lua, etc.. replace Swift with C#, Kotlin, Java, Go, Scala, etc.. and replace C++ with Rust, Zig or C.

But if you mix the families, i say you will have a hard time using Python or C++ in the wrong places.

And this rule is also valid for Rust unfortunately.

* Note: i know this is subjective and a lot of people would find it more beautiful than Swift instead. Its ok and even good that we dont all have the same tastes.

Post reply on HN