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

321–330 of 402 posts

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

#321

Post by pjmlp »

miffy900 wrote: post #303
vbezhenar wrote: post #239

Does it mean Objective C is going to be second-class language? It would be a pity, I prefer Objective C to Swift.

Seems so. I often wonder what things would be like if Apple had improved upon Objective-C by fixing up the underyling C language. Yeah it'd no longer be a superset of C, but so what? Neither is Swift. Swift is great but I wish it was closer to Objective-C in spirit by deliberately being a more lightweight language. It's language spec is gargantuan - they've pretty much succeeded in making it a language as complex as…

Not up to date? They already made most of what was possible without breaking compatibility.

https://medium.com/ios-os-x-development/generics-in-objectiv...

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

#322

Post by seanalltogether »

Gigachad wrote: post #215
seanalltogether wrote: post #188

Earlier quoted context omitted.

Inheritance is about providing business logic in all downstream inheritors through a super() chain. If you want shared logic in Rust between several implementors of a trait you will probably end up with duplicate code. There are drawbacks to both.

You can solve duplication with macros to implement traits. The Rust way seems to provide the same convenience without the runtime costs.

Macros provide code injection, that's not the same thing. Inheritance allows for overrides so you can have [default super logic]+[custom child logic]. That's only possible in rust with a lot of copy and paste, which can be fragile to maintain long term. Most UI frameworks are built around inheritance to guarantee logic provided by the base view or view group, while allowing for inheritors to mix in custom logic as well

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

#323

Post by yazaddaruvala »

dataangel wrote: post #277
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…

I've been writing rust recently and trying to figure out how to write generic traits using higher ranked trait bounds with understanding variance sufficiently to know I'm not creating a soundness hole is much more difficult for me than writing C++. It's like all the template hackery madness you needed to resort to to do anything mildly interesting in C++98, except it's in the core idioms of the language.

> trying to figure out how to write generic traits using higher ranked trait bounds with understanding variance sufficiently

I agree! You’re currently dealing with writing non-ergonomic Rust.

I’d argue your domain is missing a fundamental reusable library/framework or the framework is currently missing a piece. Once someone publishes the needed library (hopefully it’ll be you) then everyone consuming it can just Lego block multiple crates together. Lego blocking crates together (barring heavy macro crates) is very ergonomic.

95% of all new code written is Lego blocking other crates. 5% of new code written is to build new or improve/patch crates.

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

#324

Post by vbezhenar »

secretsatan wrote: post #312
vbezhenar wrote: post #239

Does it mean Objective C is going to be second-class language? It would be a pity, I prefer Objective C to Swift.

I used to too, it took me a while to switch, but now I see the benefits. Obj-c does give a lot more freedom, and sometimes you still need it, but what initially felt restrictive does actually lead to less buggy and predictable code, and some protocols like codable cut out massive amounts of code. I still rely on some stuff like GCD that isn't very swift like, there still isn't anything as fine grained in Swift, but I…

My issue with Swift is that it changes faster than I can learn it. I'm not Apple developer, I just write some code for macOS or iOS sometimes, like one time a year. I learned Objective C few years ago and this knowledge is with me. learned Swift 1 but now it's different and it seems that I have to learn it again almost from the scratch.

For professional *OS development Swift probably makes sense. But if I occasionally need to write some code, Objective C for me is preferred. May be Swift is stabilized enough already...

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

#325

Post by yupis »

jrochkind1 wrote: post #242

Who else remembers when they re-implemented the (at the time version of) the Foundation framework in Java for WebObjects? That was, what, 1998? Right around when NeXT got re-absorbed by Apple, not sure if the rewrite was started before or after. https://developer.apple.com/library/archive/documentation/Le... https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-... Those were the days! Actually kind of amazing…

What happened to WebObjects? And why did Apple left the business market?

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

#326

Post by yazaddaruvala »

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.

I’ve worked professionally with Java, Scala, C++, Python, Rust, JavaScript, Typescript, Ruby.

None of them are ergonomic for non-trivial applications!

The goal is to appropriately abstract away the super minority of code that deals with the non-trivial parts into a nice ergonomic interface.

Rust is frankly better than most in the list above at allowing the writer to create an ergonomic interface. Yes it’ll take the writer 3x as long in the short term to create the ergonomic interface but:

1. Relative to everything else creating/maintaining these types of internal abstractions is a super minority of time spent reading and writing code.

2. Unlike other languages, you’ll end up with fewer iterations of the interface because it’ll push the author to really understand the complete interface, rather than shipping a buggy interface that needs iteration. Also refactoring is Rust is simpler than any other of the listed languages (because it self documents more assumptions).

3. The ergonomic interface likely has already been published as a crate. I.e. don’t need to write it at all. These internal abstractions are more likely to be written in their first pass as general purpose than in other languages because of the collaborative design working with the rustc compiler.

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

#327

Post by mpweiher »

astrange wrote: post #219
mpweiher wrote: post #50

Earlier quoted context omitted.

You don't have a link to the data because this is not true. Swift is generally slower than Objective-C, often significantly so. There are cases where it is faster, but those are rare. Yes, I have measured. One example is JSON and Swift codable, which is comically slow, see: Somewhat Less Lethargic JSON Support for iOS/macOS, Part 1: The Status Quo https://blog.metaobject.com/2020/04/somewhat-less-lethargic-... Punch…

This largely depends on how much of Swift ObjC bridging you'll hit, as such it'll get faster if more of Foundation is converted to Swift. In particular Swift is more memory efficient than ObjC because there's less boxing overhead to small values. That should matter more than the overhead from more overflow checking.

> SwiftObjC bridging

This is another commonly held belief that doesn't hold up to actual measurements.

For an example, see part 2: https://blog.metaobject.com/2020/04/somewhat-less-lethargic-...

All the pure Swift implementations are even slower than the bridged ones, and the bridged ones are slower than the most comically inefficient Objective-C one (using KVC, for example), which is slower than the reasonable Objective-C ones.

> In particular Swift is more memory efficient than ObjC ...

It's not.

> ... because there's less boxing overhead to small values

You would think, yes. I actually did think that as well. Because it really sounds plausible. So imagine my surprise when I measured some common cases for my book (Chapter 9) and it turned that even in the cases where I just knew™ that Swift would be faster, because of this very reason, it just wasn't.

> That should matter more than the overhead from more overflow checking.

Computers don't care what you think "should" be the case, and they cannot be argued into better performance due to plausible arguments and strongly held beliefs.

You need to measure what actually is the case.

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

#328

Post by lapcat »

sunshinerag wrote: post #308
lapcat wrote: post #210

Earlier quoted context omitted.

Free labor for the world's most profitable corporation. Looking forward to it. And then they still take a cut of your revenue.

You also mean “paid labour From the worlds most profitable corporation” right?

No?

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

#329

Post by j-f1 »

vbezhenar wrote: post #324
secretsatan wrote: post #312

Earlier quoted context omitted.

I used to too, it took me a while to switch, but now I see the benefits. Obj-c does give a lot more freedom, and sometimes you still need it, but what initially felt restrictive does actually lead to less buggy and predictable code, and some protocols like codable cut out massive amounts of code. I still rely on some stuff like GCD that isn't very swift like, there still isn't anything as fine grained in Swift, but I…

My issue with Swift is that it changes faster than I can learn it. I'm not Apple developer, I just write some code for macOS or iOS sometimes, like one time a year. I learned Objective C few years ago and this knowledge is with me. learned Swift 1 but now it's different and it seems that I have to learn it again almost from the scratch. For professional *OS development Swift probably makes sense. But if I occasionall…

There were a lot of changes made in the Swift 1–3 time frame as the team learned what it was like to write Swift at scale and developed a unique language style. That’s all done now, and Swift 5 code (released 2019) should continue to be compilable with few exceptions long into the future. It’s different enough from Swift 1 that it’s basically a different language though.

The biggest source-breaking change on the near-term horizon (which is still in progress) is compile-time enforcement of concurrency safety.

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

#330

Post by yyyk »

rattray wrote: post #199
yyyk wrote: post #149

Earlier quoted context omitted.

>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?

Well that's easy. Swift is: 1. Much more expressive and featureful than Go 2. More concise and modern than C# (debatable maybe?) 3. Less JVM than Kotlin (the apples-to-apples; Java is a much worse language) 4. Way, way faster and more typesafe than Python 5. Better support for parallel execution (and probably fine-tuning other performance knobs) than TypeScript

1. Definitely, but Go is well very optimized for concurrent network apps.

2. I think the C# team has done very well modernizing. The runtime is a bit of a bother though.

3. There's Kotlin/Native and Kotlin/JS.

4. Python has dev speed and ML benefits.

5. If you're going this way, performance probably isn't your main goal?

All-in-all, Swift is interesting, but (IMHO) lackluster crossplatform support and toolchain is a problem.

Post reply on HN