Chris Lattner Formally Steps Down From Swift's Core Team

[Debunez]

With Swift, developers lost the ability to directly consume C and C++ APIs via Obj-C and Obj-C++ respectively. Now they need to find and maintain bindings which tend to rot quite badly. To be fair, Rust suffers from this too; the FFI / bindgen stuff is not a substitute for direct inclusion of a header.

So whilst C and C++ are not the most comfortable languages to develop with, I really do see Objective-C making a comeback and ultimately outliving Swift.

That is actually not true. Swift is able to directly consume C API with no bindings needed. There was also support for C++ being developed in the swift llvm repo, but I don't know what the status of that is anymore.

[kpedersen]

That is actually not true. Swift is able to directly consume C API with no bindings needed.

XCode does some amount of "importing" and generating of bindings:

https://developer.apple.com/document...tions_in_swift

However if you have a C header file containing MACROs, structs, function pointers, Swift cannot directly consume this. The languages are fundamentally different. The tooling can generate matching "things" for structs and function pointers but this is really just binding generation. The biggest issue is here:

https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_macros_in_swift

C macros that are more complex than simple constant definitions have no counterpart in Swift.

Not entirely Swift's fault. I can't exactly state that "The biggest bug with Swift is that it is not C". However sometimes this does tend to feel to be the case.

[Vistaus]

With this I am not saying that swift is the best language. But it's miles ahead of any of the other C derivatives for its intended purpose.

Call for Swift in the kernel instead of Rust?

[Debunez]

XCode does some amount of "importing" and generating of bindings:

https://developer.apple.com/document...tions_in_swift

However if you have a C header file containing MACROs, structs, function pointers, Swift cannot directly consume this. The languages are fundamentally different. The tooling can generate matching "things" for structs and function pointers but this is really just binding generation. The biggest issue is here:

https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_macros_in_swift

Not entirely Swift's fault. I can't exactly state that "The biggest bug with Swift is that it is not C". However sometimes this does tend to feel to be the case.

My point still stands. You do not need *bindings* for C API's using Swift. Btw, I wrote all my swift code on Linux so Xcode is pretty much irrelevant. I was using xcb libraries directly in Swift. Just import and start typing. Where is the friction there?

[kpedersen]

My point still stands. You do not need *bindings* for C API's using Swift. Btw, I wrote all my swift code on Linux so Xcode is pretty much irrelevant. I was using xcb libraries directly in Swift. Just import and start typing. Where is the friction there?

It does look like you need bindings, but the tooling automatically generates them (kind of like SWIG, etc).
Out of interest, what is the tool that generates the bindings? I thought this was done by the IDE (which was a bit annoying). Is it as simple as running

swiftc <source>

?

OK, so it looks fairly powerful in terms of its binding generation for xcb. This is good to see. Do you envision that it can also wrap something quite high level like Gtk+ 2/3 including callbacks and things like that?

[Debunez]

It does look like you need bindings, but the tooling automatically generates them (kind of like SWIG, etc).
Out of interest, what is the tool that generates the bindings? I thought this was done by the IDE (which was a bit annoying). Is it as simple as running

swiftc <source>

?

OK, so it looks fairly powerful in terms of its binding generation for xcb. This is good to see. Do you envision that it can also wrap something quite high level like Gtk+ 2/3 including callbacks and things like that?

The issue with GTK as mentioned in your post and on the official Swift C compatibility page, is that GTK has heavy use of specialized macros. Swift pukes trying to consume these, so I think for libraries like GTK you would need to re-implement those macros within the bridging header (this is basically a header file that just includes the necessary C header files for the library to support an alias import statement in Swift). I think for something like GTK, supporting a gobject-introspection based binding generator for Swift would probably the way like all other languages that try to support GTK.

But for simpler libraries, such as SDL or GLFW. Swift can use them as is (though some of the syntax will be a little clunky). I've tried writing Vulkan code in Swift in the past, but handling raw cstrings (for a lot of the layer and extension setup) is rough... Ultimately i ended up just going back to C as its my preferred language anyway. But I still have a place in my heart for Swift.

[microcode]

I honestly don't see the point of Swift, especially since you basically have to use Objective C interop just to get a working app on iOS. Even something as simple as the return key being a submit on the last field of a form (e.g. a login form) is completely impossible with SwiftUI, and good luck finding out how to work around that, with Apple's extremely awkward and unhelpful documentation.

[vegabook]

Swift has a REPL which is one thing I love about it vs Rust (I'm a data scientist).

[coder]

It's interesting to read tidbits about Swift and the drama in its community. Well, the latter part is sad, I guess, but I can't completely decouple it from my feelings about Apple.

Anyway, my first thought, upon seeing the headline was "OMG, how did he even have time?". Chris seems like an incredibly busy individual, in his senior role at SiFive (VP Engineering) and now with his own firm, not to mention any involvement he still has with LLVM.

I still can't care. IMO, working with Apple isn't much different than the PRC. They'll tolerate you as long as you're useful, but you're ultimately disposable to them and have zero actual clout.

If you misread the dynamic, you get hurt. It's the kind of relationship you stay in only for as long as it serves your own interests. If you want to do something lofty, look elsewhere.