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

141–150 of 402 posts

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

#141

Post by Octokiddie »

The article quotes this:

> With a native Swift implementation of Foundation, the framework no longer pays conversion costs between C and Swift, resulting in faster performance.

and this:

> A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation).

First, that range of 1.5x-18x is kind of huge. Why?

Second, why would the intro with C be such a big performance penalty even assuming it's just 1.5x? I know there must be an overhead, but why so large?

Also, why single out the Calendar? Is it somehow representative?

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

#142

Post by kybernetyk »

nicoburns wrote: post #136
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.

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.

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

#143

Post by deathanatos »

eimrine wrote: post #24
hinkley wrote: post #18

Earlier quoted context omitted.

I really should have started using Long Bets years ago. Ten years ago a “Tanya” told me she would never use an ebook to read literature. I’m pretty sure if I went to her house today I’d find 2. In fact I may be the only person I know who doesn’t own one (not wanting one and being fundamentally against them are two different things). That’s the most memorable but I’ve had these sorts of “over my dead body” conversatio…

Maybe Tanya reads a lot of PDF as kind of default format for all kinds of technical things and very common format for downloadable ebooks. AFAIK ebook readers are terrible in pdf rendering.

> AFAIK ebook readers are terrible in pdf rendering.

They're not really comparable formats. PDFs are documents rendered onto virtual paper: there is only so much a mobile device can do there, as a PDF is likely rendered as an 8½ by 11 or A4, which isn't going to be great on a tiny mobile screen. Bad tradeoffs between tiny text or pan-and-scan.

eBooks, OTOH, are reflowable: ePub is "just" a ZIP of HTML¹. But the viewer can lay them out appropriately, so they can be formatted to fit your device, whether that's a tablet, a phone, or something else.

IMO if you want to read something on a device, ePub > PDF for those reasons. PDF is good for print, & ensuring that what comes out of the printer has a shot at resembling the screen. (Though there are a good number of print settings to mess that up, too.) And, as a passably portable document format, if you're just doing short term viewing or something.

¹Plus a lot of other metadata that I'm eliding; it's a fair bit more complicated, of course.

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

#144

Post by vkou »

Octokiddie wrote: post #141

The article quotes this: > With a native Swift implementation of Foundation, the framework no longer pays conversion costs between C and Swift, resulting in faster performance. and this: > A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation). First, that range of 1.5x-18x is kind of huge. Why? Second, why would…

More importantly, why single out something like date calculation? Does that really eat a meaningful number of CPU cycles that needs to be optimized?

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

#145

Post by dvh »

Octokiddie wrote: post #141

The article quotes this: > With a native Swift implementation of Foundation, the framework no longer pays conversion costs between C and Swift, resulting in faster performance. and this: > A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation). First, that range of 1.5x-18x is kind of huge. Why? Second, why would…

I know nothing about their c codebase but I assume it's because when the language is hard, you tend to keep it as simple as possible. When every line stops being a foot gun, you start using optimizations you wouldn't dare before.

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

#146

Post by lmm »

FlyingSnake wrote: post #103
kitsunesoba wrote: post #85

Earlier quoted context omitted.

My experience is probably colored by .NET/WinUI but when I was dabbling in writing a Windows desktop app a few months ago I can't say I loved C#. My background has no Java in it so maybe that's why, but a lot of things that come standard as part of Swift seem to be in external libraries with .NET/C#, and it felt like some things were different for the sake of being different. Point in case, with Swift and Kotlin I've…

> some of these don't have a 1:1 equivalent in C# which was a huge hit to productivity This is interesting because all these magical functions (zip, map, Rx etc) have roots in LINQ which sprung from .Net world. I find it hard to believe that the battle tested CLR and C# doesn't have the equivalent functions.

> all these magical functions (zip, map, Rx etc) have roots in LINQ which sprung from .Net world

No they don't. They're essentially unchanged from ML back in the 1970s. The part that was new in C# was the SQL-like syntax on top of them, and most subsequent languages haven't considered that worth adopting.

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

#147

Post by manmal »

password1 wrote: post #127
manmal wrote: post #41

Earlier quoted context omitted.

Yes, and it means Swift scripts and modules that don’t reference UIKit/AppKit/SwiftUI/Combine will run on Linux and possibly Windows with zero or little modification. I‘m a little sad though that they didn’t start this endeavor years ago, because IMO Rust has already built so much momentum that it will win (for the popular, medium to long term definition of „winning“).

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.

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 interesting - they tried to write memory safe C and invested heavily, but admitted defeat eventually - and started using Rust. And I think that’s what will happen at most companies eventually. Rust has a lot going for it (faster than C sometimes, excellent WASM support etc). Swift might have been another contender, but Apple kept things too close to their chest for too long IMO.

As another poster wrote, Swift certainly won’t die at Apple (and their ecosystem), and Google will certainly keep Go alive. But I think Rust will eventually be used at many/most other companies for anything security or performance critical. Maybe it will replace C as the de facto low level language.

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

#148

Post by lmm »

dcow wrote: post #20

I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. And that's coming from a Rust fan. It will be interesting to see how effective this rewrite is.

> I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform.

Sure, or really OCaml or any other language with ML-family features (other replies have already mentioned Kotlin or C#). But the fact that it took Rust to get adoption and not OCaml suggests that it's not language functionality that drives adoption; Rust has something that those languages don't. (My theory is that it succeeds by being the first decent language that can match C's performance-on-silly-microbenchmark numbers)

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

#149

Post by yyyk »

dcow wrote: post #70
rattray wrote: post #47

Earlier quoted context omitted.

Interesting. Asking as someone who's never programmed with Swift or Rust, but is familiar with the syntax/ideas of each, I'm curious why you say that?

If you don't care about performance and "zero cost abstractions" and are more interested in Rust for its memory safety, then most of your Rust programs end up with a lot of syntactic and library bloat to add those "costly" (but convenient) abstractions back in, like explicitly cloning or wrapping types in Rc and Arc or just always taking ownership of borrowed data by constructing owned types with it. And then there a…

>If you don't care about performance and "zero cost abstractions" and are more interested in Rust for its memory safety...

Just about GC language has similar tradeoffs. The question here would be why Swift over Go/C#/Java/Python/Typescript?

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

#150

Post by qaq »

ChrisMarshallNY wrote: post #38

This will take a while, but I'm looking forward to it. It's probably another big step towards "Swift everywhere," without worrying about bridging to C. I've been doing little but Swift since 2014, and really like the language. I'm still "on the fence" about SwiftUI, but that's mostly because of the level of support from Apple, and the [im] maturity of the system. This will help with that.

Waiting for things to settle down on the server side and will gladly use Swift for web APIs once dust settles as the lang is really nice for the most part.
Post reply on HN