[mac-mc]

There are a bunch of design decisions in Swift that make it more C++ with the corresponding binary bloat + other issues than reference counted Java/Smalltalk with a C FFI that Obj-C is.

You could've had Obj-C without the C for example, ADTs (enums), strong nullability enforcement and a nicer syntax while reusing most of the Obj-C core and retaining the compile speed, rock solid / fast debugging, function calls as data (selectors), easy mock creation and so on.

The systems programming capabilities is lost on %99.9 actual usage of swift. The swift project should've been split into two different projects IMO, where they modernized Obj-C into a successor language without making the C++ choices they did and created SwiftRust where the %0.1 that want system programming and nondeterministic multithreading capabilities can go do so. Apple second system effect-ed themselves hardcore with the Swift project, and it shows everywhere.

https://en.wikipedia.org/wiki/Second-system_effect

[jshier]

Sounds like you want Mojo, Lattner's statically typed language built on Python. In any case, the language you describe wouldn't be compatible with Obj-C except through an import layer like Swift. "Obj-C without the C" is meaningfully impossible.

And it's funny you mention systems programming, since Swift is still relatively bad at that compared to C++ or Rust, and most of its improvements in that area are recent and ongoing. It'll be another release or two before the memory movement features are fully in place and the language allows full control over ownership (without unsafe heroics at least).

[pjmlp]

Chris Lattner is on record that isn't something that Apple really cared about, and all Objective-C improvements starting with Objective-C 2.0 were already steps into improving the interoperability with what be later known as Swift.

Safe system programming is one of the key design goals from Swift.