8 ms·

Interoperability: Swift’s Super Power

156 points by tambourine_man 3y ago

jahansyed 3y ago
Based on the title I really thought this would about the SWIFT (messaging system) and interoperability (Interledger protocol). I really need to stop reading crypto articles. Its taking over my tech side.
- hiAndrewQuinn 3y ago
  SWIFT as in the Fintech/banking thing? It's amazing how fast my memory of things goes after I switch jobs, I had to ask ChatGPT to refresh my memory. """ SWIFT stands for the Society for Worldwide Interbank Financial Telecommunication. It is a global messaging network used by banks and financial institutions to securely and efficiently exchange information, particularly for international money transfers and transactions. SWIFT codes are used to identify banks and facilitate the transfer of funds between them. It plays a crucial role in international banking and financial communication. """ I didn't know SWIFT was involved at all in crypto stuff, at least not directly. I guess finance is the world's most interconnected network, however, so I shouldn't be too surprised.
  - rz2k 3y ago
    Many people outside of the finance industry first learned about SWIFT when it was in the news that Russian banks had been excluded from the network as a consequence of their country’s violations of international law and attempt to conquer Ukraine. SWIFT’s relevance to cryptocurrency is most likely the cryptocurrency community’s aspirations of creating an alternate method for transferring wealth that is not limited by international borders or implicitly required to respect international sanctions. Legally, citizens in countries respecting the international law can still be liable for violating sanctions regardless of the method they use to transfer assets, so I don’t completely understand the how cryptocurrency is a superior way to launder money when the transactions occur on a public block chain.
- altdataseller 3y ago
  I thought it was about Taylor Swift and how she crashed Ticketmaster and it’s interoperability systems
- andyjohnson0 3y ago
  We clearly need namespaces for product names :)
terhechte 3y ago
I would like to see a comparison of how this compares to Rust. In terms of interoperability it has Cxx (https://cxx.rs https://cxx.rs) to offer safe bindings to C++ but also has great support for Android, Linux and many other systems. You don't even need to hack together Windows bindings (as explained in the blog post) because Microsoft offers official bindings (https://crates.io/crates/windows https://crates.io/crates/windows). I'm not sure if I'd call it a superpower if any potential interoperability has to be written to be used (compared to it already being available). Or rather, in comparison to what is interoperability a Swift superpower? Certainly not C++ or C which can be used in a far wider set of targets.
- zozbot234 3y ago
  Swift simply has good interop with shared objects written in Swift. You're not forced to go through a raw C ABI for everything, whereas you have to do that in Rust (unless your shared objects are part of the same build). There are crates to make interop a bit easier, but they're not standard in any real sense. The flip side though is that once you have to build a raw C API/ABI for your shared object written in Rust, it becomes usable with any other language that has good FFI with C, which is most of them.
- zer0zzz 3y ago
  I've worked both with the Swift C++-Interop project and I've also spoken to the author of cxx.rs a little bit. The two approach the problem differently. Swift's approach is that you only need to provide a header (which you likely already have), and the compiler does all the rest to handle the bridging for you. cxx.rs' approach is that you use this crate to write a bridging file and so long as you follow the type set that cxx.rs understands you have a bridge (int, char, std::string, std::unique_ptr etc). They're both good approaches but the Swift approach is definitely much more ambitious and more user-friendly to the programmer.
auggierose 3y ago
I don't know, I left Swift (although I like the language) because it is not interoperable whatsoever, in the sense that you can use it on whatever platform you like. I switched to TypeScript.
- cageface 3y ago
  I happily made the switch from Obj-C to Swift when it was announced, partly because Apple said they wanted to make it a true cross platform language. So far that doesn't seem to have really happened and in the meantime I've switched to Typescript and more recently Dart (for Flutter), which currently both have much better cross platform stories.
  - auggierose 3y ago
    Yes, exactly. Interoperable doesn't mean much if it is not properly cross platform. I've tried Dart for a project, and it worked OK, but in my opinion TypeScript is clearly the way to go in the foreseeable future.
    - pjmlp 3y ago
      Typescript is limited by V8 capabilities, and the constraints of a dynamic language JIT. To achieve best perfomance one needs to write C++ code as native modules. Interoperable means a lot even inside Apple ecosystem, bringing all those C, Objective-C and now C++ code with ease into Swift projects. Using Metal from Swift, althought implemented in Objective-C and C++, is already a productivity boost compared to anything that Microsoft has ever produced for .NET in regards to DirectX, not even XNA.
      - auggierose 3y ago
        If you are on the Apple platform only, Swift is great, and I enjoyed using Metal myself. But eventually I accepted how much it limited what I can do as a developer. So, I prefer TypeScript now. I am not touching C++ or stuff like that, if I need performance, I compile to web assembly, hopefully soon from my own language :-)
K0nserv 3y ago
I'm quite bullish on this method of cross-platform i.e. a common shared core leveraging native UI toolkits. Every incarnation of cross-platform on the market today sits somewhere between mediocre and bad in terms of the resulting UX. This approach strikes a good balance between sharing code and being platform native I think. Swift is a good contender for doing this and so is, I think, Rust.
- bt4u 3y ago
  [dead]
- jamil7 3y ago
  I feel like the problem with Swift in this context is its relationship with Foundation, its standard library. There are at least three versions of it now. The internal version that ships with Apple OSes, then are the forks swift-corelibs-foundation and swift-foundation, these are, as far as I know, incomplete or behave slightly differently on Linux. swift-foundation is the newest and most likely the future. However, it's unclear when or if it will ever be production ready. Apple doesn't appear to be dedicating that much engineering effort towards it right now.
  - mplewis9z 3y ago
    Eh, I wouldn’t call Foundation its standard library - it sits somewhere in between your traditional stdlib (including things like Date/Time models) and third-party dependencies (things like networking requests). There’s no functionality in Foundation that is absolutely core to the language and that you can’t avoid. I agree with you the various forks are confusing, but disagree that Apple isn’t putting effort towards the new one - it was only announced earlier this year, and is looking like it will be ready for WWDC is 2024. Which, given the sheer scope of the project (completely rewriting everything from the ground up in Swift), would be quite a fast turnaround time.
    - jamil7 3y ago
      > There’s no functionality in Foundation that is absolutely core to the language and that you can’t avoid. Is that why they're splitting the newer one into further SPM modules? There seems to be "FoundationEssentials" listed in that package. > but disagree that Apple isn’t putting effort towards the new one - it was only announced earlier this year, and is looking like it will be ready for WWDC is 2024 Oh, interesting, where did you find this information? I follow the project on Github and got the impression it had slowed down since its announcement.
pjmlp 3y ago
On the same note, watch Apple's talk at CppCon 2023, "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw
- zengid 3y ago
  This was an awesome talk. I really wish he went more into their plans to put Swift in the kernel and the bullet point of expecting the language to "scale down to a minimal runtime" (~7:41).
  - jumhyn 3y ago
    There's some elaboration in this forums post on "Embedded Swift": https://forums.swift.org/t/embedded-swift/67057 https://forums.swift.org/t/embedded-swift/67057
- dep_b 3y ago
  This is why I often skip the article and go straight to the comments on HN! "Emergency recovery can be handled by a supervisor process" - this sounds a lot like Elixir to me, but I can't find any example in Swift.
mugivarra69 3y ago
wouldnt mojo have same thing theoretically ?
mpweiher 3y ago
Hmm...Swift never struck me as a particularly interoperable design. Really rather the opposite. It has weird and super-specific calling conventions, requires mangled identifiers, is uber-static, uses Swift syntax for its "module" files etc. And it turns out... "Instead, Swift embeds a copy of clang, the C and C++ compiler," ...well gosh, you can brute force "interoperability" by simply creating the union of all the languages you "interoperate" with. https://www.youtube.com/watch?v=XqUgUgiToNs https://www.youtube.com/watch?v=XqUgUgiToNs "The F4 Phantom, America's proof to the world that with a big enough engine, even a brick can fly"
- Tarq0n 3y ago
  Sounds like the precursor to what Lattner is trying to do with Mojo: embed everything into a Frankenstein of a compiler and runtime. Time will tell if such a thing is maintainable.
  - mpweiher 3y ago
    I think we already have fairly overwhelming evidence that it is not.
- deleted 3y ago
  [deleted]
- pohl 3y ago
  Don’t forget that this interoperability was put in place to support a specific engineering goal: to make it possible to slowly (over decades, probably) transition from 4 different languages (C, ObjC, C++, ObjC++) at every level of Apple’s stack towards a single memory-safe successor language. Would you recommend they wait for some weird Java-esque 100% Pure implementation within the compiler itself before they can begin that work? The ideal you’re suggesting is actually made more reachable by this work. One can imagine a Swift LLVM/Clang now. See: https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw
  - stephen_g 3y ago
jxdxbx 3y ago
“Learnings” is nails on a chalkboard.
vi4m 3y ago
Interoperability is about practicality and performance cost. I think Swift is quite practical and efficient in this regard - from day 1 it has near-zero C-lang integration costs, and now it has C++ support. Also, https://github.com/swiftwasm https://github.com/swiftwasm shows how the modularity pays off. Comparing it to the other languages that got stuck with incompatible frame conversion (Golang) or JIT memory management problems (JVM) it's not bad at all.
vitiral 3y ago
I assumed this was about Taylor Swift and her supper power of appealing to all groups of fans. > Instead, Swift embeds a copy of clang, the C and C++ compiler... Ah... interoperability through a non-swappable fork of a behemoth piece of software just for your project. I don't see what could go wrong?
- stephen_g 3y ago
  My understanding is that they're talking about the Swift compiler having an embedded Clang, not embedding Clang into all binaries. So no, not much that can go wrong, the Swift and Clang compilers are both part of the same wider LLVM ecosystem so marry together neatly to be able to provide this interoperability.
ChrisMarshallNY 3y ago
> Instead, Swift embeds a copy of clang, the C and C++ compiler May have something to do with Swift’s original author. llvm is probably one of the most important inventions in decades.
Dungenesst 3y ago
[dead]

Based on the title I really thought this would about the SWIFT (messaging system) and interoperability (Interledger protocol). I really need to stop reading crypto articles. Its taking over my tech side.

hiAndrewQuinn 3y ago
SWIFT as in the Fintech/banking thing? It's amazing how fast my memory of things goes after I switch jobs, I had to ask ChatGPT to refresh my memory. """ SWIFT stands for the Society for Worldwide Interbank Financial Telecommunication. It is a global messaging network used by banks and financial institutions to securely and efficiently exchange information, particularly for international money transfers and transactions. SWIFT codes are used to identify banks and facilitate the transfer of funds between them. It plays a crucial role in international banking and financial communication. """ I didn't know SWIFT was involved at all in crypto stuff, at least not directly. I guess finance is the world's most interconnected network, however, so I shouldn't be too surprised.
- rz2k 3y ago
  Many people outside of the finance industry first learned about SWIFT when it was in the news that Russian banks had been excluded from the network as a consequence of their country’s violations of international law and attempt to conquer Ukraine. SWIFT’s relevance to cryptocurrency is most likely the cryptocurrency community’s aspirations of creating an alternate method for transferring wealth that is not limited by international borders or implicitly required to respect international sanctions. Legally, citizens in countries respecting the international law can still be liable for violating sanctions regardless of the method they use to transfer assets, so I don’t completely understand the how cryptocurrency is a superior way to launder money when the transactions occur on a public block chain.
altdataseller 3y ago
I thought it was about Taylor Swift and how she crashed Ticketmaster and it’s interoperability systems
andyjohnson0 3y ago
We clearly need namespaces for product names :)

terhechte 3y ago

I would like to see a comparison of how this compares to Rust. In terms of interoperability it has Cxx (https://cxx.rs https://cxx.rs) to offer safe bindings to C++ but also has great support for Android, Linux and many other systems. You don't even need to hack together Windows bindings (as explained in the blog post) because Microsoft offers official bindings (https://crates.io/crates/windows https://crates.io/crates/windows). I'm not sure if I'd call it a superpower if any potential interoperability has to be written to be used (compared to it already being available). Or rather, in comparison to what is interoperability a Swift superpower? Certainly not C++ or C which can be used in a far wider set of targets.

zozbot234 3y ago
Swift simply has good interop with shared objects written in Swift. You're not forced to go through a raw C ABI for everything, whereas you have to do that in Rust (unless your shared objects are part of the same build). There are crates to make interop a bit easier, but they're not standard in any real sense. The flip side though is that once you have to build a raw C API/ABI for your shared object written in Rust, it becomes usable with any other language that has good FFI with C, which is most of them.
zer0zzz 3y ago
I've worked both with the Swift C++-Interop project and I've also spoken to the author of cxx.rs a little bit. The two approach the problem differently. Swift's approach is that you only need to provide a header (which you likely already have), and the compiler does all the rest to handle the bridging for you. cxx.rs' approach is that you use this crate to write a bridging file and so long as you follow the type set that cxx.rs understands you have a bridge (int, char, std::string, std::unique_ptr etc). They're both good approaches but the Swift approach is definitely much more ambitious and more user-friendly to the programmer.

auggierose 3y ago

I don't know, I left Swift (although I like the language) because it is not interoperable whatsoever, in the sense that you can use it on whatever platform you like. I switched to TypeScript.

cageface 3y ago
I happily made the switch from Obj-C to Swift when it was announced, partly because Apple said they wanted to make it a true cross platform language. So far that doesn't seem to have really happened and in the meantime I've switched to Typescript and more recently Dart (for Flutter), which currently both have much better cross platform stories.
- auggierose 3y ago
  Yes, exactly. Interoperable doesn't mean much if it is not properly cross platform. I've tried Dart for a project, and it worked OK, but in my opinion TypeScript is clearly the way to go in the foreseeable future.
  - pjmlp 3y ago
    Typescript is limited by V8 capabilities, and the constraints of a dynamic language JIT. To achieve best perfomance one needs to write C++ code as native modules. Interoperable means a lot even inside Apple ecosystem, bringing all those C, Objective-C and now C++ code with ease into Swift projects. Using Metal from Swift, althought implemented in Objective-C and C++, is already a productivity boost compared to anything that Microsoft has ever produced for .NET in regards to DirectX, not even XNA.
    - auggierose 3y ago
      If you are on the Apple platform only, Swift is great, and I enjoyed using Metal myself. But eventually I accepted how much it limited what I can do as a developer. So, I prefer TypeScript now. I am not touching C++ or stuff like that, if I need performance, I compile to web assembly, hopefully soon from my own language :-)

K0nserv 3y ago

I'm quite bullish on this method of cross-platform i.e. a common shared core leveraging native UI toolkits. Every incarnation of cross-platform on the market today sits somewhere between mediocre and bad in terms of the resulting UX. This approach strikes a good balance between sharing code and being platform native I think. Swift is a good contender for doing this and so is, I think, Rust.

bt4u 3y ago
[dead]
jamil7 3y ago
I feel like the problem with Swift in this context is its relationship with Foundation, its standard library. There are at least three versions of it now. The internal version that ships with Apple OSes, then are the forks swift-corelibs-foundation and swift-foundation, these are, as far as I know, incomplete or behave slightly differently on Linux. swift-foundation is the newest and most likely the future. However, it's unclear when or if it will ever be production ready. Apple doesn't appear to be dedicating that much engineering effort towards it right now.
- mplewis9z 3y ago
  Eh, I wouldn’t call Foundation its standard library - it sits somewhere in between your traditional stdlib (including things like Date/Time models) and third-party dependencies (things like networking requests). There’s no functionality in Foundation that is absolutely core to the language and that you can’t avoid. I agree with you the various forks are confusing, but disagree that Apple isn’t putting effort towards the new one - it was only announced earlier this year, and is looking like it will be ready for WWDC is 2024. Which, given the sheer scope of the project (completely rewriting everything from the ground up in Swift), would be quite a fast turnaround time.
  - jamil7 3y ago
    > There’s no functionality in Foundation that is absolutely core to the language and that you can’t avoid. Is that why they're splitting the newer one into further SPM modules? There seems to be "FoundationEssentials" listed in that package. > but disagree that Apple isn’t putting effort towards the new one - it was only announced earlier this year, and is looking like it will be ready for WWDC is 2024 Oh, interesting, where did you find this information? I follow the project on Github and got the impression it had slowed down since its announcement.

pjmlp 3y ago

On the same note, watch Apple's talk at CppCon 2023, "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw

zengid 3y ago
This was an awesome talk. I really wish he went more into their plans to put Swift in the kernel and the bullet point of expecting the language to "scale down to a minimal runtime" (~7:41).
- jumhyn 3y ago
  There's some elaboration in this forums post on "Embedded Swift": https://forums.swift.org/t/embedded-swift/67057 https://forums.swift.org/t/embedded-swift/67057
dep_b 3y ago
This is why I often skip the article and go straight to the comments on HN! "Emergency recovery can be handled by a supervisor process" - this sounds a lot like Elixir to me, but I can't find any example in Swift.

mugivarra69 3y ago

wouldnt mojo have same thing theoretically ?

mpweiher 3y ago

Hmm...Swift never struck me as a particularly interoperable design. Really rather the opposite. It has weird and super-specific calling conventions, requires mangled identifiers, is uber-static, uses Swift syntax for its "module" files etc. And it turns out... "Instead, Swift embeds a copy of clang, the C and C++ compiler," ...well gosh, you can brute force "interoperability" by simply creating the union of all the languages you "interoperate" with. https://www.youtube.com/watch?v=XqUgUgiToNs https://www.youtube.com/watch?v=XqUgUgiToNs "The F4 Phantom, America's proof to the world that with a big enough engine, even a brick can fly"

Tarq0n 3y ago
Sounds like the precursor to what Lattner is trying to do with Mojo: embed everything into a Frankenstein of a compiler and runtime. Time will tell if such a thing is maintainable.
- mpweiher 3y ago
  I think we already have fairly overwhelming evidence that it is not.
deleted 3y ago
[deleted]
pohl 3y ago
Don’t forget that this interoperability was put in place to support a specific engineering goal: to make it possible to slowly (over decades, probably) transition from 4 different languages (C, ObjC, C++, ObjC++) at every level of Apple’s stack towards a single memory-safe successor language. Would you recommend they wait for some weird Java-esque 100% Pure implementation within the compiler itself before they can begin that work? The ideal you’re suggesting is actually made more reachable by this work. One can imagine a Swift LLVM/Clang now. See: https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw
- stephen_g 3y ago

jxdxbx 3y ago

“Learnings” is nails on a chalkboard.

vi4m 3y ago

Interoperability is about practicality and performance cost. I think Swift is quite practical and efficient in this regard - from day 1 it has near-zero C-lang integration costs, and now it has C++ support. Also, https://github.com/swiftwasm https://github.com/swiftwasm shows how the modularity pays off. Comparing it to the other languages that got stuck with incompatible frame conversion (Golang) or JIT memory management problems (JVM) it's not bad at all.

vitiral 3y ago

I assumed this was about Taylor Swift and her supper power of appealing to all groups of fans. > Instead, Swift embeds a copy of clang, the C and C++ compiler... Ah... interoperability through a non-swappable fork of a behemoth piece of software just for your project. I don't see what could go wrong?

stephen_g 3y ago
My understanding is that they're talking about the Swift compiler having an embedded Clang, not embedding Clang into all binaries. So no, not much that can go wrong, the Swift and Clang compilers are both part of the same wider LLVM ecosystem so marry together neatly to be able to provide this interoperability.

ChrisMarshallNY 3y ago

> Instead, Swift embeds a copy of clang, the C and C++ compiler May have something to do with Swift’s original author. llvm is probably one of the most important inventions in decades.

Dungenesst 3y ago

[dead]