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

371–380 of 402 posts

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

#371

Post by sixstringtheory »

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…

In addition to what replies have already pointed out to you, guard places the assigned new variable in the same scope below. This encourages early exits and avoids pyramids of doom.

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

#372

Post by Gigachad »

metaltyphoon wrote: post #355
sacnoradhq wrote: post #131

Earlier quoted context omitted.

None. It's code organizational syntactic sugar and abstraction that incurs a runtime penalty (vtables). Go ditched OO for similar reasons. Haskell, Erlang, and more get along fine without OO. (OO crested with Smalltalk, Java, Ruby, Python, and JS (more prototypal though). Let's not talk about C++98)

Don’t trait objects work the same way as vtables (fat pointer)?

Monomorphisation solves this. The compiler duplicates functions for every type you use them with in the finished binary.

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

#373

Post by [deleted] »

manmal wrote: post #67
ChrisMarshallNY wrote: post #49

Earlier quoted context omitted.

I don't particularly care, whether or not Swift ever leaves the Apple ecosystem (like ObjC). In that domain, Rust will never "win." I think that Rust is an awesome server language, though, and I'm glad to see it gain traction. I just hope that it doesn't get trashed by a bunch of junk dependencies, written in it. I find using apps written, using hybrid systems, or PWAs, to be quite painful (on Apple devices -and that…

I think whoever „wins“, it would be necessary to have good interop at least. Currently, Rust devs are integrating core libs into native iOS apps by going the C route. All this work to make everything memory safe, and then this.

[deleted]

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

#374

Post by kibibu »

pjmlp wrote: post #300
jrochkind1 wrote: post #253

Earlier quoted context omitted.

Huh, Foundation was developed for EOF? (Enterprise Object Framework; it was actually very much like Rails ActiveRecord). I did not realize that, I always figured it came first.

There were already many Rails like frameworks when it came to be, I never understood the hype, specially since I was part of one written in TCL back in 1999, whose core team went on to create OutSystems in 2001.

The "scaffold" demo really drove the hype.

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

#375

Post by Zababa »

wbl wrote: post #268
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…

If it was just a matter of avoiding memory safety Java and ML were right there, and these languages are pretty different from each other. It's not just memory safety. Go gets motivated by highly concurrent systems with large numbers of programmers and prioritized simplicity and developer experience. Rust was aiming at very high performance at the extended of complexity and compile times, and Swift wanted to build UI…

ML is still right there, and yet people are adding its features to more popular languages (recently Java). OCaml had a compiler to JS released in 2010 (js_of_ocaml), yet Typescript was still released 2 years later. Is this because of technical concerns? NIH syndrome? Lack of knowledge about absolutely everything that has been done? A need for control? Probably a bit of each, and other things too.

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

#376

Post by Zababa »

yazaddaruvala wrote: post #180
kybernetyk wrote: post #142

Earlier quoted context omitted.

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.

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…

> The Rust web server frameworks are approaching the ergonomics of Typescript web server frameworks.

I don't think that's true at all, at least it wasn't for me. Async in Rust has always been hard for me, it seems that using it requires knowing about how exactly it works and how your runtime of choice works. This is a lot, and requires a lot of time.

The documentation in Rust is above average, however the Rust ecosystem tends to be very unstable. Libraries often pull lots of depencies, many of which aren't even in 1.0, some that have switched to a new version but still have docs made for the old. The guideline from semantic versioning is to release 1.0 as soon as people start depending on it, since the idea is to version the public API. This is not always respected. And goes hand in hand with libraries that are 4 years old and on version 12 or something.

I remember actix-web before the 4.0 being particularly hard to get into.

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

#377

Post by Zababa »

jurip wrote: post #264
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.

Rust is pretty often chosen also in places where performance is not that critical. It has a good ecosystem, a good type system, native builds and great performace. Those factors make it a good choice in places where you'd be just fine even if it was slightly slower. If Swift loses by a small margin — and Swift is a high performance language too — it could very well edge out Rust with ergonomics.

Also great build tool and IDE support. Cargo and rust-analyzer by themselves make me not miss a GC that much.

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

#378

Post by pjmlp »

ribit wrote: post #363
pjmlp wrote: post #320

Earlier quoted context omitted.

Given that all modern language support most OOP concepts, phasing out is not happening any time soon.

By OOP I mean entangling of behavior and type hierarchy (mainstream class-based OOP aka. C++ OOP). Dot-notation and methods do not equate OOP. But of course, it depends on your definition. Pretty much anything can be called “OOP” if one wants to.

Ah so interfaces/traits/type classes hierarchies suddenly isn't OOP, nor dynamic /static method dispatch with type polymorphism, got it.

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

#379

Post by pjmlp »

tialaramex wrote: post #367
pjmlp wrote: post #361

Earlier quoted context omitted.

Java, Kotlin and C++. The languages with tier 1 support on Android SDK tooling for app development, properly configured out of the box after a SDK full install. https://developer.android.com/guide/components/fundamentals Which by the way, also includes a phone emulator to try out your stuff, including simulation of hardware events. No need to get a phone.

> Java, Kotlin and C++. I just tried this and... no C++. You can add the NDK and start building stuff with C++, but that's also exactly how the Rust offering works. If the result was actually a properly configured out of the box C++ development environment that would be pretty nice besides the Android stuff, but it isn't, the actual result out of the box is you get to pick Java or Kotlin. You can do C++ native develo…

Since when does Rust appear as language selection on the NDK installer?

Has out of the box support on Android Studio for:

- mixed language debbugging

- project templates wizard

- code completion and linting

- JNI bindings generation

- two way editing between native JNI wrappers and Java/Kotlin native method declaration

- packaging of Android libraries for native code

And for game developers, if they so which, plugins for Visual Studio with similar capabilities.

In both cases, official support from Android team if there are issues with the above tooling.

Apparently you haven't tried enough, if you think bare bones NDK integration with cargo is enough for Android shops.

Maybe Rust will get on https://developer.android.com some day, but it isn't there today, even despite the fact that it is being used for Android internals, there is zero documentation on how to write Android drivers in Rust.

https://source.android.com/docs/core/architecture

So lets not pretend it is the same effort using Rust on Android, as it is for the official SDK languages.

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

#380

Post by pjmlp »

colejohnson66 wrote: post #357
pjmlp wrote: post #314

Earlier quoted context omitted.

Java made the mistake of being VM based, no value types, and AOT only available via expensive 3rd party plugins. Had Java been like Modula-3 or Eiffel since version 1.0, Go might never have happened at all. Thankfully they are on the right path to fix those issues.

So Microsoft created C# to address that

No it didn't, it created C# because they got sued by Sun due to the J++ extensions, none of them were related to value types and AOT.

J++ extended Java in having a Windows specific framework JFC, Java Foundation Classes, what later became Windows Forms.

Support for events and J/Direct, which is basically how P/Invoke came to be on C#.

.NET has always supported a basic kind of AOT via NGEN, which only supports dynamic linking, AOT has to be done at install time, requires strong named Assemblies and it is tailored for fast startup leaving the rest of the work to the JIT.

If it wasn't for the lawsuit, C# would never happened, in fact the research being done with COM vNext used J++.

Post reply on HN