Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving the usability of C libraries in Swift

swift.org

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Improving the usability of C libraries in Swift

#21

Post by pinnochio »

mpweiher wrote: post #13
skrrtww wrote: post #3

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…

> ... some of the more recent complex language features This isn't recent. The approach that Swift took had this path locked in from the start, the (d)evolution towards ever more spiraling complexity was inevitable from the initial choices. And this is not 20/20 hindsight, a lot of people, including yours truly, were saying that fron the very start. As an example, take initialization: 2014: https://blog.metaobject.co…

I was excited and optimistic about transitioning to Swift in the Swift 3 days. By Swift 5 I was pining for Objective-C.

One of the arguments for switching to Swift was that it would be easier for new programmers. Now I think it's more of a barrier than Obj-C ever was.

Re: Improving the usability of C libraries in Swift

#22

Post by mpweiher »

pinnochio wrote: post #21
mpweiher wrote: post #13

Earlier quoted context omitted.

> ... some of the more recent complex language features This isn't recent. The approach that Swift took had this path locked in from the start, the (d)evolution towards ever more spiraling complexity was inevitable from the initial choices. And this is not 20/20 hindsight, a lot of people, including yours truly, were saying that fron the very start. As an example, take initialization: 2014: https://blog.metaobject.co…

I was excited and optimistic about transitioning to Swift in the Swift 3 days. By Swift 5 I was pining for Objective-C. One of the arguments for switching to Swift was that it would be easier for new programmers. Now I think it's more of a barrier than Obj-C ever was.

I don't pine. I use.

Although more and more I am shifting to Objective-Smalltalk: https://objective.st

Re: Improving the usability of C libraries in Swift

#23

Post by pinnochio »

mpweiher wrote: post #22
pinnochio wrote: post #21

Earlier quoted context omitted.

I was excited and optimistic about transitioning to Swift in the Swift 3 days. By Swift 5 I was pining for Objective-C. One of the arguments for switching to Swift was that it would be easier for new programmers. Now I think it's more of a barrier than Obj-C ever was.

I don't pine. I use. Although more and more I am shifting to Objective-Smalltalk: https://objective.st

That's neat.

Unfortunately, in my place of work, going back to Obj-C isn't an option.

Re: Improving the usability of C libraries in Swift

#24

Post by pharaohgeek »

skrrtww wrote: post #3

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…

I absolutely love Swift. I find it to be such an elegant language. I've done a few macOS/iOS apps with it over the years, but have really come to love it on the server. There are a couple of areas I feel could use some improvement with respect to cross-platform support, but overall the use of frameworks like Vapor have been a breeze to work with.

More support for language interoperability like this will just enhance the cross-platform experience. The Java ecosystem is what makes it so attractive to enterprises. Swift being able to easily take advantage of open-source C/C++ libraries will help with the migration.

Re: Improving the usability of C libraries in Swift

#25

Post by zozbot234 »

skrrtww wrote: post #3

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…

> It understands what an ABI is!

Rust understands the C ABI, and that's plenty good enough for now. It's hard to guarantee safety anyway when you're linking to what's effectively outside code (not part of the same build) because we don't really have a fully typed equivalent for raw assembly or binary output (unlike your "safe" VM's, where the bytecode always undergoes sanity checks prior to execution) - hence why the raw C ABI often suffices in a practical sense.

Re: Improving the usability of C libraries in Swift

#26

Post by pharaohgeek »

andeee23 wrote: post #7
skrrtww wrote: post #3

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…

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 do miss JetBrains' AppCode and their support for Swift in CLion. I wish they would open-source those plugins so that they can continue to be used in modern versions of CLion.

Re: Improving the usability of C libraries in Swift

#27

Post by dagmx »

w10-1 wrote: post #9

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…

> so much because they realize they'll likely keep their existing low-level system+embedded code rather than port it to Swift

I disagree. I think it’s more that it reduces the burden to port to swift. Of course there’s some stuff you’ll never be able to port because of external factors, but reducing the burden to introduce a language is the first step in allowing more stuff to be shifted to that language transparently.

Re: Improving the usability of C libraries in Swift

#28

Post by dagmx »

randomNumber7 wrote: post #18

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 "un…

Your question as stated is exactly why there are so many pointer types.

Is it a pointer to raw memory or a pointer to a type? Does it have a known size? Should it be allowed to be changed?

These are all questions you have to answer in C but cannot without annotations or documentation. Languages with more expressive type systems need to map that ambiguity to something.

Re: Improving the usability of C libraries in Swift

#29

Post by budgefrankly »

mpweiher wrote: post #14
arcticbull wrote: post #10

Earlier quoted context omitted.

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

While it has gotten even worse, thinking it was clear and cohesive in the beginning is rose tinted nostalgia.

Yeah, Swift looks like someone started trying to port a C# syntax onto an esoteric object-orientated C-dialect (similar to Vala and GObject) then at the last moment noticed Rust 1.0 had been released, tried to patch on some Rust features, and hit release before they were done.

It's quite deceptive. Rust seems initially hard to learn, but it's a small language, so you arrive at competency faster than you might think. Swift seems initially easy to learn, but is a broad language with lots of edge-cases, so you're never quite as competent as you think you are, or need to be

Re: Improving the usability of C libraries in Swift

#30

Post by secretsatan »

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.

Post reply on HN