Improving the usability of C libraries in Swift
1–10 of 37 posts
Re: Improving the usability of C libraries in Swift
#2This 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
Re: Improving the usability of C libraries in Swift
#3This 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.
Re: Improving the usability of C libraries in Swift
#4This 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…
This is a good write up about Swift Concurrency: https://fuckingapproachableswiftconcurrency.com/en/
Re: Improving the usability of C libraries in Swift
#5This 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…
It feels like the language designers have never met a feature or paradigm they didn't love and agree to include :-\
Re: Improving the usability of C libraries in Swift
#6This 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…
This is a good write up about Swift Concurrency: https://fuckingapproachableswiftconcurrency.com/en/
This is awesome, and deserves its own post!
Re: Improving the usability of C libraries in Swift
#7This 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…
i’m not sure about the work on tooling
just a few weeks ago i was trying to work on a swift project in neovim and found the whole langserver experience pretty bad
and it’s way worse when working on swif ui apps, but i guess that’s more of an apple wanting you to use xcode thing.
i wish there was better tooling, i like the language, but i just switched to nim for my side project
Re: Improving the usability of C libraries in Swift
#8This 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…
i’m not sure about the work on tooling just a few weeks ago i was trying to work on a swift project in neovim and found the whole langserver experience pretty bad and it’s way worse when working on swif ui apps, but i guess that’s more of an apple wanting you to use xcode thing. i wish there was better tooling, i like the language, but i just switched to nim for my side project
I find the Swift tooling very lacking. There's no way to lint dead code, there no way to auto format the files exactly as Xcode would do it and tell the linter those rules so that it doesn't lint your auto formatted code. Xcode project files are impossible to edit except with Xcode and Xcode often has issues and I need to manually empty the build folder. These are just some of the issues I remember
Re: Improving the usability of C libraries in Swift
#9I 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.
Re: Improving the usability of C libraries in Swift
#10This 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…
It feels like the language designers have never met a feature or paradigm they didn't love and agree to include :-\
Yeah, Swift started out fairly clear and cohesive and now it's just a katamari of every language feature ever made by anyone plus a whole bunch of home-grown features too. I'm always mixed on this because in isolation the feature is neat and I like it, but the totality of Swift is becoming as overwhelming and inconsistent as C++.
Now some C functions which are indistinguishable from free Swift functions get named parameters, and you can switch on some enumerations from C, and some C objects are ref counted but other ones still need you to do it. It's going to be quite something to keep track of which library is which since there's no way to know apriori.