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

341–350 of 402 posts

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

#341

Post by manmal »

pjmlp wrote: post #317
manmal wrote: post #309

Earlier quoted context omitted.

Slight correction: Swift‘s ARC is not a GC (the compiler just inserts retain/release calls where it’s necessary), and one can write very performant code by steering clear of reference counted types, and Objective-C types (dynamic dispatch is really slow). Value types with copy-on-write shouldn’t impose much overhead. Automatic inlining is progressing nicely AFAIK, and recently introduced concurrency can collapse call…

It is definitely one per CS definition of automatic memory mangement algorithms. Compiler optimizations are exactly that, optimizations that any automatic memory mangement implementation usually takes advantage of.

I stand corrected, thanks!

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

#342

Post by steve1977 »

incrudible wrote: post #340
ChrisMarshallNY wrote: post #49

Earlier quoted context omitted.

I don't particularly care, whether or not Swift ever leaves the Apple ecosystem (like ObjC). In that domain, Rust will never "win." I think that Rust is an awesome server language, though, and I'm glad to see it gain traction. I just hope that it doesn't get trashed by a bunch of junk dependencies, written in it. I find using apps written, using hybrid systems, or PWAs, to be quite painful (on Apple devices -and that…

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.

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

#343

Post by manmal »

lapcat wrote: post #331
manmal wrote: post #309

Earlier quoted context omitted.

Slight correction: Swift‘s ARC is not a GC (the compiler just inserts retain/release calls where it’s necessary), and one can write very performant code by steering clear of reference counted types, and Objective-C types (dynamic dispatch is really slow). Value types with copy-on-write shouldn’t impose much overhead. Automatic inlining is progressing nicely AFAIK, and recently introduced concurrency can collapse call…

> 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. That's about 9 CPU cycles. In the 10.5 days it was a dozen or more, so we've seen a nice improvement. To turn this number upside down, if you did nothing but Objective-C message sends, you could do about 400 million of them per second on this computer.

So it's 9 cycles vs what, one?

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

#344

Post by steve1977 »

pjmlp wrote: post #318
avx56 wrote: post #256

Earlier quoted context omitted.

I thought it was NeXTSTEP/Sun, but it seems disputed. https://stackoverflow.com/questions/473758/what-does-the-ns-...

What they collaborated was in Distributed Objects Everywhere, which ended up becoming Java EE. https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere Their collaboration is also one of the reasons why Java is basically Objective-C semantics with C++ like syntax. https://cs.gmu.edu/~sean/stuff/java-objc.html Interfaces (protocols), dynamic class loading (plugins), RMI (distributed objects), jars (bundles), dynam…

And I guess Cocoa (the initially Objective-C based application framework for macOS) was kind of a wordplay on Java again.

It’s like Java, just sweeter ;)

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

#345

Post by lapcat »

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…

> So it's 9 cycles vs what, one?

I'm not sure what you're asking? What are you trying to compare?

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

#346

Post by tialaramex »

pjmlp wrote: post #315
dochtman wrote: post #153

Earlier quoted context omitted.

Note that Apple is known er use Rust for some of its infrastructure and Google is adopting Rust in a big way in Android and Fuchsia.

Currently the Android team doesn't have any plans to expose Rust support on the NDK/AGK, anyone going down that path is expected to support themselves in Android Studio, Gradle, CMake, android-ndk, AAR/Bundles, JNI integration.

I mean, you say "support themselves" but e.g. https://blog.rust-lang.org/2023/01/09/android-ndk-update-r25...

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

#347

Post by pjmlp »

steve1977 wrote: post #344
pjmlp wrote: post #318

Earlier quoted context omitted.

What they collaborated was in Distributed Objects Everywhere, which ended up becoming Java EE. https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere Their collaboration is also one of the reasons why Java is basically Objective-C semantics with C++ like syntax. https://cs.gmu.edu/~sean/stuff/java-objc.html Interfaces (protocols), dynamic class loading (plugins), RMI (distributed objects), jars (bundles), dynam…

And I guess Cocoa (the initially Objective-C based application framework for macOS) was kind of a wordplay on Java again. It’s like Java, just sweeter ;)

During OS X early days, Apple wasn't sure that the Mac OS developer community groomed on Object Pascal and C++, was that keen into embracing Objective-C.

So they jumped into the Java hype, created their own JVM implementation, with Swing extensions for the OS X UI, and Cocoa Bridge was born for Objective-C interop, with bindings for all key Apple techonologies like Quicktime and such.

When it became clear that Objective-C wasn't going to be an adoption problem, instead of using a 3rd party owned language, they dropped support for Java and eventually gave their implementation to OpenJDK.

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

#348

Post by pjmlp »

tialaramex wrote: post #346
pjmlp wrote: post #315

Earlier quoted context omitted.

Currently the Android team doesn't have any plans to expose Rust support on the NDK/AGK, anyone going down that path is expected to support themselves in Android Studio, Gradle, CMake, android-ndk, AAR/Bundles, JNI integration.

I mean, you say "support themselves" but e.g. https://blog.rust-lang.org/2023/01/09/android-ndk-update-r25...

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.

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

#349

Post by tialaramex »

jakewins wrote: post #137
password1 wrote: post #127

Earlier quoted context omitted.

Why do you think Swift and Rust are competing on the same grounds or for the same objective? Genuinely curious, i don't know much about Rust.

The segment in this interview where Chris talks about Rust and compares the design decisions they made in Swift tied the two languages closely in my head: https://atp.fm/371 the section on the future hopes for Swift similarly; it seems both Rust and Swift contend to replace C++ in many use cases

Lattner had a vision for a lower-level Swift, which wouldn't need the support Swift needs today - it didn't end up happening and I suspect is not practical. He talked about it in several places, but obviously by 2018 or so what Chris Lattner thinks about the future of Swift doesn't matter very much.

This "lower-level Swift" felt like a similar problem to what Carbon or Herb Sutter's Cpp2 have. They've got something that's unsafe, and they want to somehow build a safe abstraction, but that's a foundation layer, and you've already built a tower of stuff above that, so you need to build it underneath all the stuff you have, which will be way harder than what Rust did where they begin at the bottom.

Is it impossible? No. But it might well be too expensive to be pulled off in practice, especially given that you need the result to pay back your expense over and above what exists today e.g. Rust.

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

#350

Post by tialaramex »

kybernetyk wrote: post #142
nicoburns wrote: post #136

Earlier quoted context omitted.

Aside from Swift having automatic reference counting, and Rust relying more heavily on its borrow checker, Swift and are super similar languages. If what you want is an ergonomic language that lets you combine the best of ML type systems with C family imperative programming then they’re the two obvious choices.

I would not describe Rust as being particularly ergonomic. While it is a suitable replacement for C++, that is not necessarily a high standard to meet.

For me it seems to almost exactly fit my model of how things ought to work, and of course the diagnostics are so much better than most languages.

We saw the other day where C and C++ just let you write what seems reasonable but then they do something insane, D says no, that's a syntax error, but Rust's diagnostic gives a name to what you intended, says you can't do that, and suggests how to write it instead.

  if (a
C and C++ think that's doing a comparison, coercing the boolean result to whatever type to compare it with the remaining variable, and then acting on the new boolean result. D says that's a syntax error because there should be a closing parenthesis after the variable "b". Rust says "comparison operators cannot be chained" and suggests a Edited to add:

Swift says: adjacent operators are in non-associative precedence group 'ComparisonPrecedence' -- which is definitely better than D, but it doesn't offer the helpful suggestion.

Post reply on HN