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

11–20 of 37 posts

Re: Improving the usability of C libraries in Swift

#11

Post by pjmlp »

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…

That is surely the target for Apple platforms, whatever happens outside is more a nice to have kind of thing.

As proven by the track record of all languages that want to be simple, created as kind of anti-trends, they always tend to evolve into complexity as their userbase grows, as it turns out other programming language didn't got complex just for fun.

Then since they were initially created as kind of anti-complexity movement, the added on features always have warts due to not wanting to break compatibility, and are only half way there.

C23 versus PL/I, ALGOL variants, Scheme R7RS (full report) vs Lisp evolution, Java 26 vs Modula-3/Eiffel, Go 1.26 versus everyone, ...

Re: Improving the usability of C libraries in Swift

#12

Post by isodev »

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).

Re: Improving the usability of C libraries in Swift

#13

Post by mpweiher »

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.com/2014/06/remove-features-for-grea...

The swift book has 16 rules and 14 pages just on object initialization. Chris replied in the comments: "the complexity is necessary for and thus simplicity must give way". My reply: "the is incompatible with simplicity and thus must give way".

2020:

called it!

https://blog.metaobject.com/2020/04/swift-initialization-swi...

---

Or the syntax:

https://blog.metaobject.com/2020/06/the-curious-case-of-swif...

→ Swift included all of Smalltalk's keyword message syntax as a special case of a special case of the method call syntax.

---

Rob Rix:

“Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).”

https://www.quora.com/Which-features-overcomplicate-Swift-Wh...

Re: Improving the usability of C libraries in Swift

#14

Post by mpweiher »

arcticbull wrote: post #10
aaronbrethorst wrote: post #5

Earlier quoted context omitted.

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

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

Re: Improving the usability of C libraries in Swift

#17

Post by gregoriol »

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…

Sure they will keep C/C++, and various low-level code: Swift is nice for developers but slow for execution (compared tose).

Re: Improving the usability of C libraries in Swift

#18

Post by randomNumber7 »

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.

Re: Improving the usability of C libraries in Swift

#19

Post by worldsavior »

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…

All the benefits you mentioned are trivial, as in- many languages have them already.

Re: Improving the usability of C libraries in Swift

#20

Post by nicoburns »

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…

Yep. They also have a history of strong C/C++ interop with objective-c being based on C and objective-c++ (which allows compiling C++ and objective-c in one code file) also being a thing. I bet part of this is a good migration path for code (Apple and 3rd party) that uses that.
Post reply on HN