Earlier quoted context omitted.
Kotlin seems kinds of pointless with the features in newer Java versions
Would Java had advanced without Kotlin on its doorstep?
Yes, because Kotlin hardly matters in regards to the JVM.
Apple is rewriting Foundation in Swift
211–220 of 263 posts
Re: Apple is rewriting Foundation in Swift
#212Earlier quoted context omitted.
What would you use instead of ref counting? Swift is an embedded language for Apple’s own chips, they can optimize the hell out of refcounting at silicon level.
Modern, state-of-the-art, generational GC? Not being snarky, that’s literally the comparison.
There was never any way to implement a modern GC while keeping compatibility with Objective-C, which was the primary design goal of Swift.
Apple had a bad experience with GC in ObjC with libauto and learned their lesson that C and GC just don’t mix. You can never have a truly modern GC in C, because C cannot provide any of the guarantees that a GC needs to move objects around.
Using a modern GC entails sealing the language off in a bubble. Since Swift is mostly used to interface with system frameworks, you would end up paying a cost when interfacing with the system frameworks written in ObjC, making your modern GC useless most of the time.
Re: Apple is rewriting Foundation in Swift
#213Earlier quoted context omitted.
From what I've seen the ref counting can cause a big performance hit. Maybe this has improved in the last couple years?
Apple has always been preferential to reference counting (see Objective C) and it seems like they may have spent a fair bit of effort optimizing Apple Silicon for it.
Reference counting on Objective-C was plan B, after the failure of implementing a safe tracing GC in a language with C's semantics.
So they went with plan B, having the compiler automate the retain/release messages used by the Cocoa framework.
Everywhere else in Objective-C, the memory is still manually managed, or via memory pools.
Re: Apple is rewriting Foundation in Swift
#214Earlier quoted context omitted.
One of the interesting side effects of this is that those new libraries are going to have significantly worse introspection and hotpatching opportunities, so they better code them correctly, or things are going to really suck.
Would you mind to elaborate why this is the case? I am not in Swift/Obj-c ecosystem so I'm just clueless.
Obj-c is basically a dynamic language on top of C, whereas in Swift most things are statically determined at compile time.
Re: Apple is rewriting Foundation in Swift
#215Earlier quoted context omitted.
> How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc. Typically you would write more protocol-oriented code - rather than using inheritance (which is mostly there for Objective-C compatibility) you define protocols and implement them for types. This is a lot closer to traits in Rust than interfaces in Java. Among o…
So just like lots of Objective-C code, including the old NeXTSTEP Kits?
Swift's protocols are an evolution of protocols in ObjC. They offer additional features to make them safer and easier to write.
Re: Apple is rewriting Foundation in Swift
#216The performance "optimizations" are all about eliminating the bridge between ObjC and Swift. I'd love to see a comparison of how the functions work within their own realm, e.g.: - Speed of a date function in pure ObjC, tested in ObjC realm with no Swift bridge - Speed of the same date function in pure Swift, tested in Swift realm with no ObjC bridge. Otherwise, introducing an extra bridge with the language, then gett…
> Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline. This is a strange comment, because Swift would have been Dead On Arrival in 2014 without that Objective-C bridging, an Apple-created language that doesn't work with Apple application frameworks.
Perhaps I articulated incorrectly.
The bridge should have obviously existed (and should still exist for a very long foreseeable future if not forever). I was refering to having a benchmark with and without bridge and telling Swift is faster is a bit off, as that performance decrease was what Swift had to bring in the first place.
Re: Apple is rewriting Foundation in Swift
#217Earlier quoted context omitted.
What makes you say that? I don't think you can find many developers that would be willing to go back to Objective C.
Not sure why the only alternative to Swift is "going back", particularly when Swift is already going back in many ways. How about going forward to an alternative that actually isn't a step back.
That will only happen by moving to another platform.
Re: Apple is rewriting Foundation in Swift
#218Not a popular opinion. Current Apple and Swift felt somewhat like Apple and Dylan in the 90s. May be time could tell. A lot of people hate Objective-C, and was cheering for Swift in 2014. Now nearly a decade later, it seems time and resources could have been spent somewhere else.
Not really, Dylan failed to ship on NewtonOS, Swift not only is shipping across all Apple platforms, it is replacing Objective-C.
Metal is the only green field framework that was still being built with Objective-C, and yet most just use the Swift bindings.
Maybe Swift isn't Objective-C without C, as originally announced, but something else isn't coming to replace it either.
Re: Apple is rewriting Foundation in Swift
#219Swift has been a hugely successfully language. Mostly at slowing down iOS runtime performance per clock cycle, and increasing compilation times. Its also been hugely successful at punishing companies for using it, since it didnt really work for a few versions. While there have been fewer crashes (sort of) due to the switch, as someone who worked for years in Objective C and years in Swift, I honestly never felt that…
Given karismatic a prize.
I wonder if the current state of affairs is what Chris L had in mind?
Re: Apple is rewriting Foundation in Swift
#220Earlier quoted context omitted.
> Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline. This is a strange comment, because Swift would have been Dead On Arrival in 2014 without that Objective-C bridging, an Apple-created language that doesn't work with Apple application frameworks.
Perhaps I articulated incorrectly. The bridge should have obviously existed (and should still exist for a very long foreseeable future if not forever). I was refering to having a benchmark with and without bridge and telling Swift is faster is a bit off, as that performance decrease was what Swift had to bring in the first place.
Do you mean as some kind of Swift vs. Objective-C argument?
I don't think Apple is interested in having that argument in 2023. There's no point. Swift has won the "language war", politically within Apple and in developer mindshare outside Apple. (I say this as someone who continues to write Objective-C.)