Remix.run Logo
vintagedave 4 hours ago

I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language.

(There's a decent argument it encountered it in iOS and macOS too.)

[1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.

[2] https://medium.com/goodones/pareto-optimal-apple-devtools-b4...

cosmic_cheese 3 hours ago | parent | next [-]

Obj-C’s simplicity can be nice, but on the other hand I don’t miss having to bring in a laundry list of CocoaPods to have features that are standard in Swift. I don’t miss maintaining header files or having to operate in old codebases that badly manage Obj-C’s looseness either.

anextio 2 hours ago | parent | prev | next [-]

>[1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.

These kinds of features are not intended for use in daily application development. They're systems-language features designed for building high performance, safe, very-low-level code. It will be entirely optional for the average Swift developer to learn how to use these features, just in the same way that it's optional for someone to learn Rust.

glhaynes an hour ago | parent [-]

The "Swift has too many keywords now" meme makes me want to go insane. The vast majority of Swift code never runs into any of that stuff; so, what advocates of it are saying is in effect "we don't want Swift to expand into these new areas (that it has potential to be really good at) even if it's in a way that doesn't affect current uses at all."

That said, the Swift 6 / Strict Concurrency transitions truly have been rough and confusing. It's not super clear to me that much of it could have been avoided (maybe if the value of Approachable Concurrency mode had been understood to be important from the beginning?), and the benefits are real, but my gut feeling is that a lot of the "Swift is too complicated" stuff is probably just misplaced annoyance at this.

jshier 31 minutes ago | parent [-]

Swift's concurrency story is what happens when a multi-year project meets Apple's fixed six month Swift release timeline. And being written by highly knowledgeable but low level engineers who've never written an iOS app in their life, means that there was a huge approachability whole they've only recently worked their way out of, but even that has major issues (MainActor default on in Xcode but not Swift itself).

tarentel 3 hours ago | parent | prev | next [-]

I go back and forth. I do miss the simplicity of objc at times though. I think in a short amount of time someone can become close to an expert in objc. Swift is already incredibly complicated and there's no end in sight.

nicoburns 2 hours ago | parent | prev [-]

> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.

Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting.

I think the way to think about it is that with Rust, it's as if all the goodness in Swift was implemented with in the "C" level, and the Objective-C but is still just library-level a runtime layer on top. Whereas Swift brings it's own runtime which greatly complicates things.

gbanfalvi 2 hours ago | parent | next [-]

I would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system, explicit lifetime for objects, much more expressive (and therefore complex) macro support...

I get that there's a tradeoff. Rust requires you to be way more explicit about what you're intending upfront and that can, in the long term, lead to simpler code -- but there's no dimension (depth-wise or breadth-wise) that I'd call Rust simpler.

mojuba an hour ago | parent [-]

> I would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system

Swift already does have those things but unlike Rust, they are opt-in.

Not going to argue which language is simpler, but sorry, you don't seem like someone who knows Swift very well.

needlesslygrim 44 minutes ago | parent [-]

While Swift now has the `borrowing` and `consuming` keywords, support for storing references is nonexistent, and the only way to return/store `Span`s, etc, is only possible through using experimental `@lifetime` annotations.

Swift is a nice language, and it's new support for the bare necessity of affine types is a good step forward, but it's not at all comparable with Rust.

lenkite an hour ago | parent | prev | next [-]

Rust is still more complicated than Swift, but you needn't worry - the Swift team is flexing their muscles hard to ensure that Swift becomes the biggest, most complicated language on Earth and wins the complexity, cognitive burden and snail performance once and for all eternity. Their compiler already times out on the language, soon even an M7 will also give up.

estebank 2 hours ago | parent | prev | next [-]

One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.

coliveira an hour ago | parent [-]

C++ is trying to make C easier to use for 40 years, and it's still not there. So I wouldn't call that easier.

astrange 2 minutes ago | parent [-]

C++ is trying to make something EASIER to use?

zer0zzz 2 hours ago | parent | prev [-]

Except the entire design of swift is meant to make everything more automated.

* automated exclusivity with value types and value witness tables, classes as arc types (ie Arc<Mutex<T>>)

* automated interop with C/C++/Obj-C through the clang ast importer

Maybe they could have started with rust and added on what they needed, but why not build a new language at that point where things so fundamental are involved?

Source: I worked in lattners org at the time of swifts inception (on an unrelated backend) but that was the motivation. I also worked on the swift compiler for a little bit some years later on in my career.