“Learnings” is nails on a chalkboard.
Interoperability: Swift’s Super Power
11–20 of 74 posts
Re: Interoperability: Swift’s Super Power
#12Hmm...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.
Re: Interoperability: Swift’s Super Power
#13I 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.
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.
Re: Interoperability: Swift’s Super Power
#14Hmm...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…
[deleted]
Re: Interoperability: Swift’s Super Power
#15I'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.
[dead]
Re: Interoperability: Swift’s Super Power
#16I 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.
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.
Re: Interoperability: Swift’s Super Power
#17Hmm...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…
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.
Re: Interoperability: Swift’s Super Power
#18I'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.
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.
Re: Interoperability: Swift’s Super Power
#19I'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.
Re: Interoperability: Swift’s Super Power
#20Hmm...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…
If you want to interoperate with C and C++ and could either make people specify low-level details of the interface themselves or process C and C++ header files to do it automatically. Obviously the latter is a much better interoperability solution.
Processing C and C++ header files means using a C/C++ compiler. It would hardly make sense to write a new one if there was a good one already available.