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

361–370 of 402 posts

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

#361

Post by pjmlp »

tialaramex wrote: post #353
pjmlp wrote: post #348

Earlier quoted context omitted.

Nothing of that covers "Android Studio, Gradle, CMake, android-ndk, AAR/Bundles, JNI integration", which an Android shop expects to have out of the box support in the Android SDK installer. Note that android-ndk in that comment means the original Makefile based build tooling, which CMake builds still lack some corner cases in functionality, hence why I listed both.

So, just to be clear, in what languages do I not need to "support myself" under your definition and what does the "support" consist of? Do I get an Android test phone to try my software out? Is there like free phone support so I can chat to some expert in my language about Android problems? You make it sounds like a pretty big deal, but my small experience† of writing Android software a decade ago was that it just wa…

Java, Kotlin and C++.

The languages with tier 1 support on Android SDK tooling for app development, properly configured out of the box after a SDK full install.

https://developer.android.com/guide/components/fundamentals

Which by the way, also includes a phone emulator to try out your stuff, including simulation of hardware events.

No need to get a phone.

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

#363

Post by ribit »

pjmlp wrote: post #320
ribit wrote: post #313

It looks like an important step in progressively retiring ObjC. Swift is built from the start with a ObC compatibility in mind, which is a source of much ugliness and inefficiency in the language. With the Swift team working in a value semantic first language (Val), I can kind of see where this is going. Really looking forward to OOP being phased out.

Given that all modern language support most OOP concepts, phasing out is not happening any time soon.

By OOP I mean entangling of behavior and type hierarchy (mainstream class-based OOP aka. C++ OOP). Dot-notation and methods do not equate OOP. But of course, it depends on your definition. Pretty much anything can be called “OOP” if one wants to.

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

#364

Post by ribit »

flohofwoe wrote: post #316
ribit wrote: post #313

It looks like an important step in progressively retiring ObjC. Swift is built from the start with a ObC compatibility in mind, which is a source of much ugliness and inefficiency in the language. With the Swift team working in a value semantic first language (Val), I can kind of see where this is going. Really looking forward to OOP being phased out.

> Really looking forward to OOP being phased out. All the higher level macOS APIs are still object oriented, and I don't see that changing TBH. And macOS application source code is essentially just minimal glue code to tie those system APIs together, in the end, the programming language used for this glue code doesn't matter all that much, since the code is completely dominated by API calls.

Cocoa is object-oriented, but modern APIs not so much. They are of course based on interfaces/traits/protocols (whatever you want to call them) but it’s not the same as 90ies style inheritance-based OOP. It’s the inheritance as basis for behavior is what I want to see gone. But even Cocoa already embraces composition more than inheritance.

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

#365

Post by jshier »

manmal wrote: post #343
lapcat wrote: post #331

Earlier quoted context omitted.

> dynamic dispatch is really slow This is false. People believe it on faith without measuring: https://mikeash.com/pyblog/friday-qa-2016-04-15-performance-...

I have never used IMP caching, and don't think the average developer uses this (aside from indirect use of Apple's frameworks). Otherwise: > A normal Objective-C message send is a bit slower, as we'd expect. Still, the speed of objc_msgSend continues to astound me. Considering that it performs a full hash table lookup followed by an indirect jump to the result, the fact that it runs in 2.6 nanoseconds is amazing. Tha…

Or 0, given not using dynamic dispatch allows for inlining or even the compiler optimizing the call away entirely.

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

#366

Post by jshier »

meindnoch wrote: post #174
janef0421 wrote: post #62

Earlier quoted context omitted.

Swift only uses reference counting when working with objects; Structs are optimised using copy-on-write. There's currently work on implementing move and ownership semantics, similar to Rust, but opt-in rather than by default.

Ummm… No. Swift structs are just like C structs (from a memory perspective). The copy-on-write thing is implemented manually by storing a private refcounted object in your struct. See the implementation of Array for example: https://github.com/apple/swift/blob/main/stdlib/public/core/... There’s no magical copy-on-write mechanism at the language level.

I don't know why this is downvoted, it's true. There is no automatic copy on write optimization in Swift. It's a manual optimization that expensive types like Array implement manually.

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

#367

Post by tialaramex »

pjmlp wrote: post #361
tialaramex wrote: post #353

Earlier quoted context omitted.

So, just to be clear, in what languages do I not need to "support myself" under your definition and what does the "support" consist of? Do I get an Android test phone to try my software out? Is there like free phone support so I can chat to some expert in my language about Android problems? You make it sounds like a pretty big deal, but my small experience† of writing Android software a decade ago was that it just wa…

Java, Kotlin and C++. The languages with tier 1 support on Android SDK tooling for app development, properly configured out of the box after a SDK full install. https://developer.android.com/guide/components/fundamentals Which by the way, also includes a phone emulator to try out your stuff, including simulation of hardware events. No need to get a phone.

> Java, Kotlin and C++.

I just tried this and... no C++. You can add the NDK and start building stuff with C++, but that's also exactly how the Rust offering works. If the result was actually a properly configured out of the box C++ development environment that would be pretty nice besides the Android stuff, but it isn't, the actual result out of the box is you get to pick Java or Kotlin.

You can do C++ native development for Android, but only via basically the same route as Rust, there's just not the huge gap you implied.

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

#368

Post by incrudible »

steve1977 wrote: post #342
incrudible wrote: post #340

Earlier quoted context omitted.

What is a real native app? Most operating systems have multiple graphics interfaces, ui toolkits and other abstractions with varying levels of inconsistency. They could all be driven by various languages, compiled or interpreted.

macOS and iOS not so much. Which is probably one of the reasons why apps for these platforms are often much better (or at least more polished) than say Windows apps.

In my view, "polish" is rather orthogonal. For trivial apps that just assemble the building blocks that come out of the box, I'd agree. Otherwise, I find the "native" developer experience (XCode, Swift compiler) to be rather unpleasant. Moreover, the economics of developing "natively" limit the amount of polish you can actually justify.

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

#369

Post by watermelon0 »

colejohnson66 wrote: post #357
pjmlp wrote: post #314

Earlier quoted context omitted.

Java made the mistake of being VM based, no value types, and AOT only available via expensive 3rd party plugins. Had Java been like Modula-3 or Eiffel since version 1.0, Go might never have happened at all. Thankfully they are on the right path to fix those issues.

So Microsoft created C# to address that

The biggest issue with C# is that the only real implementation was closed source and Windows-only until recently.

Additionally, AOT is still experimental, and doesn't support ASP.Net Core yet.

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

#370

Post by meindnoch »

jshier wrote: post #366
meindnoch wrote: post #174

Earlier quoted context omitted.

Ummm… No. Swift structs are just like C structs (from a memory perspective). The copy-on-write thing is implemented manually by storing a private refcounted object in your struct. See the implementation of Array for example: https://github.com/apple/swift/blob/main/stdlib/public/core/... There’s no magical copy-on-write mechanism at the language level.

I don't know why this is downvoted, it's true. There is no automatic copy on write optimization in Swift. It's a manual optimization that expensive types like Array implement manually.

>I don't know why this is downvoted, it's true.

I know, right? Some people are pretty insecure…

Post reply on HN