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

281–290 of 402 posts

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

#281

Post by cellularmitosis »

cellularmitosis wrote: post #221
howinteresting wrote: post #189

Earlier quoted context omitted.

Swift would never have won, and will never win, while it's so closely associated with Apple. Many people in positions of power believe (correctly) that Apple will always put its own needs above everyone else's. Those are the people who have chosen Rust.

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.

Replying to both comments at once: I understood “win” to mean “be a viable replacement for C / C++”. A viable replacement has to meet _everyone’s_ needs, not just the needs of those for whom performance isn’t critical. And to be more specific about the performance, it isn’t by a small margin (unfortunately I no longer have the links handy, but the general trend was that Rust, C and C++ were in the same performance group, then Java, then Go, then Swift, then JavaScript. It was something like 3 to 5x slower).

I should also perhaps mention that Swift is my favorite language to develop in. I’m not trying to be antagonistic, just realistic about its prospects against Rust.

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

#282

Post by Jensson »

iamcreasy wrote: post #263
hnfong wrote: post #250

Earlier quoted context omitted.

The Foundation framework is basically the standard library of Objective C (and thus pretty much the standard library for most of the Apple ecosystem as well).

What is the Linux equivalent to Foundation Framework?

Its an API for the higher level parts of the OS, not the kernel, so that would be distribution dependent on Linux. You would build it on top of linux and make other programs program against it.

Windows has WinAPI which is basically the same thing.

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

#283

Post by cellularmitosis »

jupp0r wrote: post #265
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.

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)

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

#284

Post by [deleted] »

xp84 wrote: post #260

When the product of this hits the OS I predict massive instability. I don't think the Apple of 2022 has the level of systems programming talent that was behind the 1990s code in the core foundation. Today I feel like most of their attempts to move the OS forward beyond the shiny UI gimmicks (Tired of Exposé™? Try Stage Manager!™) are sloppy and only barely work (like "discoveryd" - google that if you don't remember).…

[deleted]

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

#285

Post by nicky0 »

xp84 wrote: post #260

When the product of this hits the OS I predict massive instability. I don't think the Apple of 2022 has the level of systems programming talent that was behind the 1990s code in the core foundation. Today I feel like most of their attempts to move the OS forward beyond the shiny UI gimmicks (Tired of Exposé™? Try Stage Manager!™) are sloppy and only barely work (like "discoveryd" - google that if you don't remember).…

You say that, but then I counter with the complete reliability and brilliance of Rosetta 2.

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

#286

Post by speedgoose »

ahepp wrote: post #276
xp84 wrote: post #260

When the product of this hits the OS I predict massive instability. I don't think the Apple of 2022 has the level of systems programming talent that was behind the 1990s code in the core foundation. Today I feel like most of their attempts to move the OS forward beyond the shiny UI gimmicks (Tired of Exposé™? Try Stage Manager!™) are sloppy and only barely work (like "discoveryd" - google that if you don't remember).…

However degraded the Apple UX is from the glory days, as someone who recently converted over from Windows I can assure you the UX there is garbage. Compared to 2022 Apple.

I don’t know, you don’t need plugins on windows to get a descent window manager. I use Rectangle and AltTab on mac, this should be default features.

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

#287

Post by Jensson »

kitsunesoba wrote: post #106
neonsunset wrote: post #105

Earlier quoted context omitted.

All these are part of standard library. Map is Select, Filter is Where, Reduce is Aggregate, etc. You can write C# in a functional style easily, it is one of the premiere features. UI frameworks on the other hand…I feel your pain.

I did find and use Select and Where at least, but I recall running into caveats with them or with their interactions with other parts of the language that meant that they couldn't be used identically. I don't remember specifically what it was since it's been a while but I remember it being frustrating. I should probably find a cheat sheet of equivalents if I try writing it again.

The C# equivalents uses SQL naming, knowing this makes it much easier to understand.

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

#288

Post by [deleted] »

mrtksn wrote: post #164
thrwawy74 wrote: post #158

Is there anything genuinely innovative about Swift or is it just another "cross-platform scripting language" that I'll only see on 1 platform? The only reason I learned Powershell is because I have to admin for Windows. At least Powershell is interesting for its pipeline and object handling. I get not one spark of joy from Swift, and the comments I see are "at least we're not writing C anymore". Stockholm syndrome. S…

It’s pleasant to use, that’s the main thing about Swift. A very Apple thing to be honest, so just like most of the Apple products it’s very good in few thing and good enough in others and probably nothing is completely new. The overall experience is pleasant. Apple is building just as pleasant tooling around it, Swift Playgrounds is amazing for example. Newbies can learn coding by doing some exercises disguised as ga…

[deleted]

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

#289

Post by [deleted] »

[deleted] wrote: post #284
xp84 wrote: post #260

When the product of this hits the OS I predict massive instability. I don't think the Apple of 2022 has the level of systems programming talent that was behind the 1990s code in the core foundation. Today I feel like most of their attempts to move the OS forward beyond the shiny UI gimmicks (Tired of Exposé™? Try Stage Manager!™) are sloppy and only barely work (like "discoveryd" - google that if you don't remember).…

[deleted]

[deleted]

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

#290

Post by fingerlocks »

nmfisher wrote: post #254
sixstringtheory wrote: post #240

Earlier quoted context omitted.

Static and concise NPE protection via optional syntax, and the guard construct, both make defensive programming much easier in Swift. Tons of other little things. Memory management is easier than it is in Rust. It has generics which makes it more flexible than Go [was until its generics were recently introduced]. Kotlin native wasn’t announced until three years after Swift. I don’t think it’s as simple or one-sided a…

I don't consider this: guard let foo = bar else { ... } to be any better than this: if bar().is_none() { ... } For the record, I find the guard keyword totally unnecessary and I still have NFI what's wrong with this in Swift: if bar == nil { ... } I also totally disagree about memory management being "easier" (at least with C-interop), because I think Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPoi…

The guard keyword behaves like a non-crashing assertion that promotes code readability with a compile-time required early exit. “Don’t bother executing past this point if these conditions are not met” is fundamentally different from “if these conditions are met create a new local scope and then continue executing”.

> Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all.

And that’s why we have inout instead? Unsafe* is useful if you need to bit pack frozen structs into a ring buffer and increment the r/w offsets by the stride, maybe? I think inout can handle that as well.

Post reply on HN