Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple is rewriting Foundation in Swift

github.com

Post reply on HN
Print view View original

201–210 of 263 posts

Re: Apple is rewriting Foundation in Swift

#201

Post by ponyous »

saagarjha wrote: post #145
zainhoda wrote: post #12

Long overdue -- there's a very noticeable difference in runtime errors with Swift libraries vs the rest. This is especially true of AVFoundation, which is an absolute mess of hidden and undocumented state. Swift optionals and enums will go a long way to fixing that.

One of the interesting side effects of this is that those new libraries are going to have significantly worse introspection and hotpatching opportunities, so they better code them correctly, or things are going to really suck.

Would you mind to elaborate why this is the case? I am not in Swift/Obj-c ecosystem so I'm just clueless.

Re: Apple is rewriting Foundation in Swift

#202

Post by lapcat »

awestroke wrote: post #165
thrwawy74 wrote: post #42

I just... completely don't understand the appeal of Swift beyond it being Apple's in-house language. I was excited for Foundation to become open-source. Using a language you'll really only find in 1 environment is a negative. I'm going to go feel ashamed for not getting excited about a language now. I should be celebrating "more languages", but Swift is just Apple. No one outside Apple chooses Shift unless they want…

The appeal of swift is that it is lightyears better than ObjectiveC. To ObjC developers that are used to being treated like trash by Apple (abysmal documentation, stone age IDE and tooling etc) that's huge

Apple's documentation was actually vastly superior before Swift. In fact, I often refer to the documentation "archive" instead of the latest docs.

The decline in the docs is due to a number of factors, but I would say mainly it's (1) the relentless annual major OS update schedule, (2) the proliferation of OS (macOS, iOS, watchOS, tvOS, xrOS?), (3) the dual language stack, (4) Apple personnel turnover.

Re: Apple is rewriting Foundation in Swift

#203

Post by lapcat »

can16358p wrote: post #117

The performance "optimizations" are all about eliminating the bridge between ObjC and Swift. I'd love to see a comparison of how the functions work within their own realm, e.g.: - Speed of a date function in pure ObjC, tested in ObjC realm with no Swift bridge - Speed of the same date function in pure Swift, tested in Swift realm with no ObjC bridge. Otherwise, introducing an extra bridge with the language, then gett…

> Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline.

This is a strange comment, because Swift would have been Dead On Arrival in 2014 without that Objective-C bridging, an Apple-created language that doesn't work with Apple application frameworks.

Re: Apple is rewriting Foundation in Swift

#204

Post by octachron »

aw1621107 wrote: post #100
wudangmonk wrote: post #45

Earlier quoted context omitted.

You can have a good type system and have fast compile times. In every single language with 'complicated type systems' it always comes down to type inference on polymorphic types which causes these issues, this has been known for over 40 years yet the same issue seems to be rediscovered again and again like it was something new. I sure hope the author learned the right lesson from the failure that is Swift and Mojo tu…

> it always comes down to type inference on polymorphic types which causes these issues Unless I'm thinking of something different, doesn't OCaml have type inference on polymorphic types and fast(ish?) compile times? I was under the impression that the breakdown of causes for Rust projects compiling slowly is very project-dependent as well. From what I can remember common culprits were monomorphization and/or LLVM, t…

Fast (and principled) inference for not-too-complicated polymorphic types is an explicit design goal for OCaml and Haskell languages. And this design goal constraint quite a lot the type system.

Typically, there are many type system features that break this property and where OCaml and Haskell requires type annotations (for instance polymorphic functions that takes polymorphic functions as arguments and use them in a polymorphic way).

As a consequence, typechecking for OCaml programs tend to take from 10% to 60% of the whole compilation time for typical programs. However, for OCaml programs that make heavy use of GADTs typechecking can dominate the compilation time (probably due to the exhaustiveness check but I have yet to empirically check that).

Infamously, Swift made the choice to introduce a typechecking algorithm with an exponential complexity in the size of expression (to support function overloading and literals) even for simple types.

Re: Apple is rewriting Foundation in Swift

#206

Post by o1y32 »

baby wrote: post #75
thrwawy74 wrote: post #42

I just... completely don't understand the appeal of Swift beyond it being Apple's in-house language. I was excited for Foundation to become open-source. Using a language you'll really only find in 1 environment is a negative. I'm going to go feel ashamed for not getting excited about a language now. I should be celebrating "more languages", but Swift is just Apple. No one outside Apple chooses Shift unless they want…

If they had waited a little bit Rust would have been a great option. That's a shame.

No, that's not possible. Just one example -- In Rust/C++, developer is responsible for managing the memory, while in Java/Swift etc the language does most of the work for you. This alone can fundamentally change many aspects of language design and mean completely different experience for developers

Re: Apple is rewriting Foundation in Swift

#207

Post by o1y32 »

olliej wrote: post #193
rvz wrote: post #137

Earlier quoted context omitted.

And? Brave (VC funded) is also a Chromium wrapper and Edge (Microsoft owned) is also one as well and both of the somehow managed to beat Firefox in usage. So what is you point? Chrome and its derivatives is the reason why browsers like Firefox is failing to keep up and continues to lose users. Using anything other than Chrome for a modern web browser is a losing battle. (Brave already tried that with Firefox and quic…

> And? I was answering a question asking what it was. Are you saying my answer was wrong? > Brave (VC funded) is also a Chromium wrapper and Edge (Microsoft owned) is also one as well and both of the somehow managed to beat Firefox in usage. Well that's just false. Firefox has 7.7% marketshare. Brave comes in at less than 1 tenth of a percent. Edge, does better after all it is the _default_ browser on the most popula…

Everyone knew IE was going away. Chrome is not, from what we can see, and is not going away any time soon. If anything, Chrome/Chromium-based browsers are eating other browsers' lunch, just look at the numbers. I absolutely hate Chrome doing their own non-standard things, but you live in a special bubble.

Re: Apple is rewriting Foundation in Swift

#208

Post by pjmlp »

dwaite wrote: post #183
mpweiher wrote: post #157

Earlier quoted context omitted.

> upgrade to OO programming with use of protocols How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc. Also, protocols in Swift have a huge performance downside, because they decided to have them work across structs and classes: if you use a protocol in a function argument, the compiler doesn't even know the size of…

> How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc. Typically you would write more protocol-oriented code - rather than using inheritance (which is mostly there for Objective-C compatibility) you define protocols and implement them for types. This is a lot closer to traits in Rust than interfaces in Java. Among o…

So just like lots of Objective-C code, including the old NeXTSTEP Kits?

Re: Apple is rewriting Foundation in Swift

#209

Post by pjmlp »

radley wrote: post #110
Illniyar wrote: post #102

Earlier quoted context omitted.

Kotlin wasn't developed for Android. And can be run anywhere. It was JetBrains pet project to fix archaic stuff in Java without making a Scala. It was designed from the get go for a wide base (as wide as java). I'm not sure how it became Android's main target, but I doubt it was the original purpose.

I think everyone jumped from Java to Kotlin due to Oracle suing Google over Java in Android. It also provided a huge opportunity to be more deliberate since Android was maturing.

That is an urban myth.

If that was the case, they would have adopted Dart instead of keeping an high dependency on the Java ecosystem for Android.

Android Studio, Gradle, Kotlin compiler, the libraries that Android depends on from Maven Central, all Java.

Re: Apple is rewriting Foundation in Swift

#210

Post by pjmlp »

d3nj4l wrote: post #99
fnord77 wrote: post #87

Earlier quoted context omitted.

Kotlin seems kinds of pointless with the features in newer Java versions

No amount of lipstick on the java pig will make it as ergonomic to use by default as kotlin.

It is enough that it is the Java Virtual Machine, not Kotlin Virtual Machine.

Hence why Kotlin only really matters on Android.

Post reply on HN