Live data from Hacker News

Interoperability: Swift’s Super Power

browsercompany.substack.com

21–30 of 74 posts

Re: Interoperability: Swift’s Super Power

#21

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 l…

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

That’s not what they do. To efficiently use C and C++ structs and classes from another language you have to know their layout and calling conventions.

With C and C++, you have to run the preprocessor and (e.g. for C++ templates) large parts of the compiler to reliably do that. How else are you going to figure out what foo_t and bar_t in header files mean?

If you need to run a compiler, using an existing compiler is the wise thing to do.

Re: Interoperability: Swift’s Super Power

#22
post #19
post #7

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.

Kotlin is a much more likely candidate. Excellent IDE support, deep integration with Java, already the go-to language for Android, many years of production and less "different" than Rust.

Kotlin running on the JVM is a disadvantage outside of Android though in a lot of spaces. Rust/Swift/Go will use a fraction of the ram to run a server application than Kotlin will.

Re: Interoperability: Swift’s Super Power

#23
post #19

Earlier quoted context omitted.

Kotlin is a much more likely candidate. Excellent IDE support, deep integration with Java, already the go-to language for Android, many years of production and less "different" than Rust.

Kotlin running on the JVM is a disadvantage outside of Android though in a lot of spaces. Rust/Swift/Go will use a fraction of the ram to run a server application than Kotlin will.

I agree, a huge driver for me leaving the Java ecosystem for Go was the JVM. Maybe Kotlin native can address that, but despite what people in the Java world seem to believe, the JVM is a big disadvantage.

Re: Interoperability: Swift’s Super Power

#24

I would like to see a comparison of how this compares to Rust. In terms of interoperability it has Cxx ( 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 ). I'm not sure if I'd call it a s…

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.

Re: Interoperability: Swift’s Super Power

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

Re: Interoperability: Swift’s Super Power

#26

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.

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 transacti…

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.

Re: Interoperability: Swift’s Super Power

#27

Earlier quoted context omitted.

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.

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.

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.

Re: Interoperability: Swift’s Super Power

#28

Earlier quoted context omitted.

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.

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.

Typescript is a safe bet.

I think for mobile apps Flutter is a better tech stack than React Native though and can survive if Google doesn’t give up on it.

Re: Interoperability: Swift’s Super Power

#29
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?

Re: Interoperability: Swift’s Super Power

#30

Earlier quoted context omitted.

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.

Typescript is a safe bet. I think for mobile apps Flutter is a better tech stack than React Native though and can survive if Google doesn’t give up on it.

That last one is a big caveat and a major reason I'm not interested in Flutter.
Post reply on HN