3 ms·

What potential roles could Swift fulfill within the Windows ecosystem? Is there a specific segment they aim to serve? One might inquire about the feasibility of

What potential roles could Swift fulfill within the Windows ecosystem? Is there a specific segment they aim to serve? One might inquire about the feasibility of developing GUI applications using Swift on Windows, particularly regarding the necessity for manual FFI bindings, given the current state of Windows-specific tooling which is largely GUI-centric. The strategy Apple employed in not prioritizing C++ as a primary language, while also introducing Swift as a new language, is quite intriguing. It raises questions about the factors contributing to its success—whether it’s a result of the approach itself or despite it.

surajrmal 2y ago
Swift was a play by Apple to make application developers (and I suppose their own internal developers) more productive. Swift absolutely became successful because it had a strong reason for developers to learn it. That said, it probably also made Apple more successful in some way as well as you cannot undercut the value of productivity.
- steve1977 2y ago
  Looking at the application landscape (and quality) in the early years of Mac OS X with Objective-C and later on with Swift, I‘m not so sure about that. Even worse when you look at Cocoa vs SwiftUI.
zerkten 2y ago
It seems like a better fit for high-end apps that want to adopt the native framework for Windows and macOS. Developers of these apps will often accept some of the quirks with manual bindings to get the performance they need while trying to maximize code sharing and minimizing divergence for as much of the shared code as possible. This is not going to be accepted by most developers on the Windows platform, but they seem out of sorts with their current options anyway.
Someone 2y ago
> One might inquire about the feasibility of developing GUI applications using Swift on Windows, particularly regarding the necessity for manual FFI bindings, How common is it to need manual FTI bindings and if so, how hard is that? Reading https://www.swift.org/documentation/cxx-interop/ https://www.swift.org/documentation/cxx-interop/ and https://forums.developer.apple.com/forums/thread/744361 https://forums.developer.apple.com/forums/thread/744361, I get the impression it’s fairly simple, if not often fully automated, and both Swift-to-C++ and C++-to-Swift calls look like normal calls in the respective languages. > The strategy Apple employed in not prioritizing C++ as a primary language, while also introducing Swift as a new language, is quite intriguing. They’re aiming to have good compatibility with existing C++ code, with all new code getting written in Swift.
cesarb 2y ago
> It raises questions about the factors contributing to its success—whether it’s a result of the approach itself or despite it. AFAIK, the main factor contributing to the success of Swift in the Apple ecosystem is probably it being the replacement for Objective-C. Unlike C or C++, which required going through Objective-C or Objective-C++ to access the native platform libraries, Swift could access them directly. That advantage does not exist on non-Apple platforms, which already have C or C++ as the most direct way to access the native platform libraries.

surajrmal 2y ago

Swift was a play by Apple to make application developers (and I suppose their own internal developers) more productive. Swift absolutely became successful because it had a strong reason for developers to learn it. That said, it probably also made Apple more successful in some way as well as you cannot undercut the value of productivity.

steve1977 2y ago
Looking at the application landscape (and quality) in the early years of Mac OS X with Objective-C and later on with Swift, I‘m not so sure about that. Even worse when you look at Cocoa vs SwiftUI.

zerkten 2y ago

It seems like a better fit for high-end apps that want to adopt the native framework for Windows and macOS. Developers of these apps will often accept some of the quirks with manual bindings to get the performance they need while trying to maximize code sharing and minimizing divergence for as much of the shared code as possible. This is not going to be accepted by most developers on the Windows platform, but they seem out of sorts with their current options anyway.

Someone 2y ago

> One might inquire about the feasibility of developing GUI applications using Swift on Windows, particularly regarding the necessity for manual FFI bindings, How common is it to need manual FTI bindings and if so, how hard is that? Reading https://www.swift.org/documentation/cxx-interop/ https://www.swift.org/documentation/cxx-interop/ and https://forums.developer.apple.com/forums/thread/744361 https://forums.developer.apple.com/forums/thread/744361, I get the impression it’s fairly simple, if not often fully automated, and both Swift-to-C++ and C++-to-Swift calls look like normal calls in the respective languages. > The strategy Apple employed in not prioritizing C++ as a primary language, while also introducing Swift as a new language, is quite intriguing. They’re aiming to have good compatibility with existing C++ code, with all new code getting written in Swift.

cesarb 2y ago

> It raises questions about the factors contributing to its success—whether it’s a result of the approach itself or despite it. AFAIK, the main factor contributing to the success of Swift in the Apple ecosystem is probably it being the replacement for Objective-C. Unlike C or C++, which required going through Objective-C or Objective-C++ to access the native platform libraries, Swift could access them directly. That advantage does not exist on non-Apple platforms, which already have C or C++ as the most direct way to access the native platform libraries.