- This is pretty great stuff, I knew about the raw interop features but had no idea what API Notes offered. Quite cool.
I can't help but feel that Swift will ultimately be the "slow and steady wins the race" safe language of the future. Swift steadily working "first" on both tooling and cohabitability with existing ecosystems is a huge boon for adoption. It understands what an ABI is! If I were doing a greenfield cross platform application I think Swift would be the first thing I reach for now.
The qualms I have with Swift are mostly some of the more recent complex language features that can make Swift code much harder to understand and read, as well as the brainpower required to use Swift concurrency. That and some performance concerns, though many of those seem like they may be solvable with optimizations in LLVM.
- I believe Apple is investing in C/C++ interop so much because they realize they'll likely keep their existing low-level system+embedded code rather than port it to Swift. That's good for people who want to do the same. A swift API layer can reduce the need for C/C++ developers.
But in my experience, there are sharp cliffs whenever you get off the happy path shown in the demos. That's not a problem with code where you can design workarounds, but when you wrap highly complex (if not arcane) C API, you often can't change or omit portions of the API causing problems. So while usability may be better, apinotes might not be enough to complete the work.
If you're wrapping something, I would recommend cataloging and then verifying all the language features you need to make it work before getting too far in.
by handstitched
0 subcomment
- This was a great read. I've used the naive approach shown in the first example before and its always felt a bit clunky, but I wasnt aware of most of these language features. I'm definitely going to try this out next time I have to write C bindings
by waffletower
0 subcomment
- I don't find Swift to be an ergonomic systems language at all. I changed career paths soon after its introduction, focussing quite a bit on Clojure (and now begrudgingly Python) as I did not find value in its "safety" and much prefer ObjC's closeness to Posix and CoreFoundation libraries in the Apple ecosystem. Objective-C is bare bones and awkward indeed, but much more facile in interacting with system libraries. the typing dances required to utilize Swift in this low level context was absurd. I would probably investigate Zig first, and Rust second and even C++ long before Swift.
- I love shitting on Apple's developer tools but they handled cross language integration really well.
Swift Package Manager handles Swift, ObjC, C, C++ in the same project, code completion works just fine. Overall much nicer than in other ecosystems.
- It's good to have options. I guess this is similar effort as Swift's java interop - created to enable internal Apple needs and a cool feature to share on socials for engagement. I don't think any of this would attract people who aren't already forced to use Swift. Generally, Apple's open source/public efforts feel more like a thing they do so they can point at this during antitrust/gatekeeper lawsuits than actual healthy foss ecosystem. (which is not a surprise of course, Apple is the opposite of foss).
by secretsatan
0 subcomment
- I wish I'd known about adding the module.modulemap file, I found out about it some time last year while making a bunch of internal libraries compatible with Swift, it works with binary frameworks too.
I'd written considerable amounts of Objective-c bridging code before that.
by woadwarrior01
0 subcomment
- PythonKit[1] could be improved significantly with these new Swift 6.2 features.
[1]: https://github.com/pvieito/PythonKit
by randomNumber7
2 subcomments
- I think Swift has great C interop but they made pointers too diffcult to use. Which of the following type do you have to use if your C API returns some pointer?
UnsafeMutablePointer, UnsafePointer, UnsafeMutableBufferPointer, UnsafeBufferPointer, UnsafeMutableRawPointer, UnsafeRawPointer, UnsafeMutableRawBufferPointer, UnsafeRawBufferPointer
?? This is comical and the only reason to make it this clunky is because "unsafe is bad" and you don't want people to use it.
by pyrolistical
0 subcomment
- Ah yes. The c abi, the thing that glues all cross lang function calls.
The human race will go extinct with the c abi still as the defacto standard at this point.
IMO any new system programming lang needs to compete over the quality of their c abi integration.
I still haven’t found a better c abi integration than zig. It can describe c funcs with higher precision than c itself.
Hacker News