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

Apple announces full Swift rewrite of the Foundation framework (2022)

infoq.com

Post reply on HN
Print view View original

391–400 of 402 posts

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#391

Post by manmal »

lapcat wrote: post #389
manmal wrote: post #384

Earlier quoted context omitted.

I’m comparing a message send with a statically linked function call (or inlining, as mentioned by sibling comment).

This has the feel of premature optimization. These are the fastest operations. Their running time starts to get overwhelmed by the slower operations as you go down the list of things tested. Making the fastest operations a few times faster doesn't necessarily have any noticeable effect on your program.

You made me think, thanks for your input. I agree that it’s not a big or unsolvable problem.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#392

Post by jen20 »

manmal wrote: post #381
jen20 wrote: post #310

Earlier quoted context omitted.

Which direction are you talking? If you want to link against Rust there is little choice but to use a C layer because it doesn’t have a stable ABI.

I‘m talking Swift > Rust. TIL about the unstable ABI, thanks!

Got it - the other way is actually fine because Swift does have a stable ABI - swift-bridge [1] allows interop in terms of high level types instead of devolving to C.

[1]: https://github.com/chinedufn/swift-bridge

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#393

Post by Reason077 »

bsaul wrote: post #382
saagarjha wrote: post #235

Earlier quoted context omitted.

Yes, it’ll be binary compatible.

i don't understand how a compiled language like swift can be binary compatible with a dynamic one like objc. How are they going to implement method swizzling on NSObject for example ?

Swift and Obj-C are both compiled languages, and also dynamic in the sense that they allow a lot of runtime introspection and dynamic dispatch.

They're already binary compatible, in the sense that you can call compiled Obj-C classes from Swift apps (of course), and also - with some restrictions - call compiled Swift code from Obj-C.

In fact, you can "swizzle" methods in Swift just like in ObjC, on classes derived from NSObject:

https://medium.com/@valsamiselmaliotis/method-swizzling-in-s...

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#394

Post by iamcreasy »

Jensson wrote: post #282
iamcreasy wrote: post #263

Earlier quoted context omitted.

What is the Linux equivalent to Foundation Framework?

Its an API for the higher level parts of the OS, not the kernel, so that would be distribution dependent on Linux. You would build it on top of linux and make other programs program against it. Windows has WinAPI which is basically the same thing.

Thanks! Can you please give a distribution specific example, such as Ubuntu/Redhat?

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#395

Post by bsaul »

Reason077 wrote: post #393
bsaul wrote: post #382

Earlier quoted context omitted.

i don't understand how a compiled language like swift can be binary compatible with a dynamic one like objc. How are they going to implement method swizzling on NSObject for example ?

Swift and Obj-C are both compiled languages, and also dynamic in the sense that they allow a lot of runtime introspection and dynamic dispatch. They're already binary compatible, in the sense that you can call compiled Obj-C classes from Swift apps (of course), and also - with some restrictions - call compiled Swift code from Obj-C. In fact, you can "swizzle" methods in Swift just like in ObjC, on classes derived fro…

What you’re doing in this medium post is call the objc runtime from swift and take advantage from swift objc bridging. This does not work if the class you’re trying to swizzle is a pure swift class. For a reason : swift is mostly static dispatch, whereas objc is pure dynamic dispatch (taking its root from smalltalk).

This means code that tried to swizzle foundation types, assuming foundation is developped in objc, will not work anymore once foundation is using a pure swift implementation.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#396

Post by bsaul »

ribit wrote: post #387
bsaul wrote: post #383

Earlier quoted context omitted.

i don't think people working on val are part of the swift team anymore.

Ah, thanks for pointing this out. I was not aware that Abrahams has left Apple...

Yeap, those past years have been pretty scary for swift. First lattner, then abraham..

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#397

Post by howinteresting »

pjmlp wrote: post #299
howinteresting wrote: post #189

Earlier quoted context omitted.

Swift would never have won, and will never win, while it's so closely associated with Apple. Many people in positions of power believe (correctly) that Apple will always put its own needs above everyone else's. Those are the people who have chosen Rust.

It is enough to win on Apple platforms.

Sure.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#398

Post by ianlevesque »

yAak wrote: post #245
pkulak wrote: post #52

Earlier quoted context omitted.

Swift is great because it's the only alternative to Objective C. I don't really think anyone is clamoring for it to move into non-Apple domains.

I would love it. Swift is fantastic, and by far my favorite language to write client code in. (Compared to Rust, TypeScript/JS, ObjC, C++, C#, & Java.)

Why do you prefer it to Rust? I don't have a horse in the race just limited time to learn languages these days.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#399

Post by up2isomorphism »

Every time like this, bunch of people who believe safe programming is a language capability will jump out.

But in fact, the most valuable part of the code in any nontrivial system is the “unsafe” yet safe ones. You write memory safe code by understanding how computers memory works, sometimes you can use certain patterns to make that process easier, but not always. This is regardless what language you use: you programming in Rust, still the most valuable part is where one can get the “unsafe” part right.

A good C programmer will always a better Rust programmer when he wants to. That’s it.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#400

Post by Reason077 »

bsaul wrote: post #395
Reason077 wrote: post #393

Earlier quoted context omitted.

Swift and Obj-C are both compiled languages, and also dynamic in the sense that they allow a lot of runtime introspection and dynamic dispatch. They're already binary compatible, in the sense that you can call compiled Obj-C classes from Swift apps (of course), and also - with some restrictions - call compiled Swift code from Obj-C. In fact, you can "swizzle" methods in Swift just like in ObjC, on classes derived fro…

What you’re doing in this medium post is call the objc runtime from swift and take advantage from swift objc bridging. This does not work if the class you’re trying to swizzle is a pure swift class. For a reason : swift is mostly static dispatch, whereas objc is pure dynamic dispatch (taking its root from smalltalk). This means code that tried to swizzle foundation types, assuming foundation is developped in objc, wi…

If Foundation is to retain binary compatibility with Obj-C, then it will by necessity still be using the Obj-C runtime, with Foundation types still extending NSObject, and thus swizzling should still work as before.

The alternative would be for Apple to break compatibility with old Obj-C apps, instead shipping a compatibility version of Foundation.framework which old apps would continue to link against. But it sounds like they're not going that route.

Post reply on HN