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

31–37 of 37 posts

Re: Improving the usability of C libraries in Swift

#31

Post by zffr »

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…

You listed 8 types, and this is because there are 3 axes that each have 2 values

- Mutable or not

- Typed or Raw

- Single object, or Buffer

Given one kind of pointer, you can convert to any other kind of pointer, but you are responsible for knowing if it’s safe to do.

The API is not super intuitive, but I can see how it makes it more clear what you are doing in your code.

Re: Improving the usability of C libraries in Swift

#32

Post by waffletower »

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.

Re: Improving the usability of C libraries in Swift

#33

Post by [deleted] »

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…

[deleted]

Re: Improving the usability of C libraries in Swift

#34

Post by Pulcinella »

budgefrankly wrote: post #29
mpweiher wrote: post #14

Earlier quoted context omitted.

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

Ehh I have been using Swift from the beginning and I disagree with you and the parent. Swift was "good" before the addition of property wrappers and the result builder syntax. That's when lots of the weird "features" started being bolted on.

Before that it just felt like what a modern OO language with reference and value types, type safety, some very light "not truly functional but nice to have" functional programming features, and readable, "normal", dot syntax would be like. The language was basically complete at that point for the purposes of writing UI apps with the existing Apple frameworks.

Re: Improving the usability of C libraries in Swift

#35

Post by ben_w »

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 was excited and optimistic about transitioning to Swift in the Swift 3 days. By Swift 5 I was pining for Objective-C.

Swift 5 isn't that bad (even if result builders felt like a weird hack to make SwiftUI possible and I dislike SwiftUI massively) but around that point the language has increasingly made me think "why did this happen when Java already existed?"

Re: Improving the usability of C libraries in Swift

#36

Post by pyrolistical »

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.

Re: Improving the usability of C libraries in Swift

#37

Post by mpweiher »

ben_w wrote: post #35
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 was excited and optimistic about transitioning to Swift in the Swift 3 days. By Swift 5 I was pining for Objective-C. Swift 5 isn't that bad (even if result builders felt like a weird hack to make SwiftUI possible and I dislike SwiftUI massively) but around that point the language has increasingly made me think "why did this happen when Java already existed?"

That was my thought from the beginning.
Post reply on HN