Interoperability: Swift’s Super Power • Hacker News Board

Re: Interoperability: Swift’s Super Power

#71

Post by stephen_g » Sat, Sep 23, 2023, 2:08 PM UTC

vitiral wrote: post #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?

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.

Re: Interoperability: Swift’s Super Power

#72

Post by zer0zzz » Sat, Sep 23, 2023, 11:23 PM UTC

terhechte wrote: post #4

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…

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.

Re: Interoperability: Swift’s Super Power

#73

Post by BrutalCoding » Thu, Sep 28, 2023, 5:13 AM UTC

nsn90 wrote: post #66

cageface wrote: post #58

Earlier quoted context omitted.

I guess you better let Apple know so they don’t accidentally make a Flutter app their app of the day again: https://flutter.dev/showcase/so-vegan

the article displays a couple of screenshots on why it's a poor experience, bottom navigation is to small and the back button is behind the camera, it's very unlikely to be fixed at the component level so devs end fixing these issues themselves by creating a new component that may not behave entirely as the system one, using the device's safe area

I don’t see the same issues you mentioned when checking the screenshots on their App Store / Play Store pages. But that was a good catch of yours.

I’m relatively confident that they used a device frame around their actual screenshots, which leads back to those issues you mentioned. You can tell that they’ve used different device frames in their current store listings compared to the realistic looking ones on the aforementioned Flutter showcase page.

This whole process can even be automated. I’m talking about a CI/CD workflow that takes screenshots of specific pages, and adding device frames around them etc. See this tool for example: https://docs.fastlane.tools/actions/frameit/

Re: Interoperability: Swift’s Super Power

#74

Post by mpweiher » Tue, Oct 03, 2023, 7:44 AM UTC

Tarq0n wrote: post #12

mpweiher wrote: post #10

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…

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.

I think we already have fairly overwhelming evidence that it is not.