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

Post by jen20 » Thu, Jan 12, 2023, 8:03 AM UTC

sidlls wrote: post #227

yazaddaruvala wrote: post #180

Earlier quoted context omitted.

Reading the super majority of Rust code is equally easy or easier than reading Python, or Typescript, or even Ruby. Writing Rust applications is also very ergonomic. The Rust web server frameworks are approaching the ergonomics of Typescript web server frameworks. The only Rudy lacking ergonomics is writing net new frameworks or missing framework pieces, or when std is not available. 95%+ of all new Rust code will fa…

This isn't really the case. Rust code is almost as complex as C or C++ for any non-trivial application.

Post by ribit » Thu, Jan 12, 2023, 8:16 AM UTC

Post by pjmlp » Thu, Jan 12, 2023, 8:48 AM UTC

dochtman wrote: post #153

manmal wrote: post #147

Earlier quoted context omitted.

I watched a Rust intro video recently that provided a perspective I liked, so I’ll share that here: MS, Apple, Google (and more) all relied heavily on C for low level code that needed to be as performant as possible. It turned out though that C‘s memory management is so problematic that many/most security issues are caused by it. To address that, Google invented Go, Apple made Swift, Mozilla gave us Rust etc. MS is i…

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.

Post by pjmlp » Thu, Jan 12, 2023, 8:51 AM UTC

manmal wrote: post #309

cellularmitosis wrote: post #221

Earlier quoted context omitted.

Swift will never win against Rust for a much simpler reason: performance. Invariably, rust is chosen where performance is critical, and Swift’s reference counting GC ensures it will never compete with Rust in those scenarios.

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…

Post by jupp0r » Thu, Jan 12, 2023, 8:58 AM UTC

cellularmitosis wrote: post #283

jupp0r wrote: post #265

Earlier quoted context omitted.

You don't need ultra performant memory management for most of your code. Swift compiles to machine code and ARC is fine for most use cases and you can use unsafe raw pointers etc for your occasional hot code path where you want to optimize memory management.

I would love to see what this looks like in practice if you can point me to a link. (I’m now curious if the unowned keyword would have similar performance characteristics)