[dilap]

Swift is an early example of Apple losing its way. Such a stark contrast to Objective-c -- which was a simple, fast compiling language that hit way above its weight for expressivity and runtime speed. A great language for its day. Swift is "a C++ hacker's first attempt at language design".

[pjmlp]

I would be fine with a Objective-C 3.0, but the big question would be how to fix the underlying C flaws, which was one of Swift's original goals.

I do agree that the language design has gone overboard in the last couple of years, expecially in the various approaches to parallelism.

However they are not alone, just look at any programming language sponsored by companies, you need features to justify team sizes and naturally old features don't go away.

[dilap]

Taste & trade-offs aside, you've gotta make it compile reasonably fast! I do get that Objective-C is not the pinacle of language development, but you shouldn't give your main language the rough edges of a research project.

(And while the past shouldn't necessarily be a shackle on the future, it is striking that such a radically different set of trade-offs was picked for Swift vs Obj-C.)

I think both Go and C# are pretty nice languages, to give you an idea of where I'm coming from. And Rust is very interesting -- as a user you see software that gets written in it exceed the previous state-of-the-art (e.g., ripgrep).

I don't see that w/ Swift. It seems like the opposite. E.g., the terrible Settings rewrite that rolled out a couple releases ago...

Confession, though, while I did a lot of ojbc back in the day, I've never done more than kick the tires on Swift, so I'm not critiquing from a position of deep knowledge -- more like talking shit from the sidelines. But I do think I'm right. ;-)

[hn-acct]

I wasn’t aware objc was considered “fast”.

[dilap]

Light-weight wrapper over C, so as fast as C when you want it to be. Message passing isn't as fast as, say, vtables, but is still quite snappy and flexible for loosely binding objects together. No generics avoids code bloat.

In practice obj-c apps were snappy, e.g., good perf on extremely limited hardware of original iPhone. SwiftUI (I assume) of MacOS settings app much slower than the old version it replaced -- too much heavy programmer framework magic resulting in slower final code? That's my diagnosis/guess from afar (I might be wrong ofc), a pitfall that objc did not tend to lead developers into.