3 ms·

Fun fact: several early Rust developers, including the initial author Graydon Hoare, switched to Apple and started working on Swift. The languages have a share

Fun fact: several early Rust developers, including the initial author Graydon Hoare, switched to Apple and started working on Swift. The languages have a shared legacy and feel quite similar in certain aspects, with Swift being a higher level adaptation. Swift is a lot easier to use, with automatic reference counting, quite a bit more convenience and syntax sugar, and a class system. It's a lovely language. It lacks what are the defining features of Rust (for me) though: low level control available when required but usually hidden behind nice abstractions, borrow checker, concurrency safeguards (Send/Sync in Rust), trait system over classes, and a good macro system. The biggest conceptual downside for me is the class system with inheritance, overrides, etc: Rust has traits that are somewhat similar to Haskell type classes, and are much nicer and more coherent to use in many domains. (it's far from perfect, especially around the severely limited trait objects and dynamic dispatch, but that is a longer topic) The biggest practical downsides are Apples disregard for other platforms (Linux/Windows are very much second/third class citizens) and the Objective-C compatibility baggage, which makes the language a bit messy. But overall I think it is easy to like and appreciate both languages.

FlyingSnake 6y ago
Yes, there's a lot of cross-pollination between Rust and Swift, and Swift devs pragmatically use features from Rust ecosystem. IMO Rust has much better FFI than Swift, but that's primarily due to Apple. I'm really stoked up for both languages to gain a larger space in developer ecosystem. > The biggest practical downsides are Apples disregard for other platforms. This is unfortunately true, but I see Swift committee making serious efforts to overcome that. I hope it gets better with time. Swift on Backend (vapor/Kitura) are simply ages behind Actix. Another language that's syntactically close is Kotlin/native, even though it has quite different goals. These 3 languages have brought much excitement to development in the past few years.
- zozbot234 6y ago
  > IMO Rust has much better FFI than Swift, but that's primarily due to Apple. How so? Swift has a stable ABI that, among other things, enables it to expose FFI bindings to many other languages. Rust has made the pragmatic choice of having no stable FFI beyond the C one, so if you want to setup FFI to a Rust library you'll have to write C-compatible wrapping code in Rust and expose that.
  - FlyingSnake 6y ago
    Swift got stable ABI in version 5, that’s bit late IMO. Also the community efforts to improve Rust interop (e.g. Rustler/Elixer) are way ahead when compared to Swift. That being said, I personally am happy that both languages to have first class FFI
    - skohan 6y ago
      > that’s bit late IMO It's pretty rare for a language to have a stable ABI, no? I mean Rust still doesn't have one.
- rvz 6y ago
  Well for creating bindings, Rust's bindgen falls short. The fact that you need to play around and switch on flags to properly recognise variables, macros and functions over a .h only for generating the FFI layer, it is just harder to maintain, even when updating the library. Swift's ClangImporter does this automatically in the language via clang modules, unlike Rust's bindgen.
skohan 6y ago
> disregard for other platforms (Linux/Windows are very much second/third class citizens) It's worth noting that improved and cross-platform support is a stated priority for the next Swift version. It's already quite usable on Ubuntu, and Windows and other Linux distros beyond Ubuntu have been added to the CI pipeline for Swift development.

FlyingSnake 6y ago

Yes, there's a lot of cross-pollination between Rust and Swift, and Swift devs pragmatically use features from Rust ecosystem. IMO Rust has much better FFI than Swift, but that's primarily due to Apple. I'm really stoked up for both languages to gain a larger space in developer ecosystem. > The biggest practical downsides are Apples disregard for other platforms. This is unfortunately true, but I see Swift committee making serious efforts to overcome that. I hope it gets better with time. Swift on Backend (vapor/Kitura) are simply ages behind Actix. Another language that's syntactically close is Kotlin/native, even though it has quite different goals. These 3 languages have brought much excitement to development in the past few years.

zozbot234 6y ago
> IMO Rust has much better FFI than Swift, but that's primarily due to Apple. How so? Swift has a stable ABI that, among other things, enables it to expose FFI bindings to many other languages. Rust has made the pragmatic choice of having no stable FFI beyond the C one, so if you want to setup FFI to a Rust library you'll have to write C-compatible wrapping code in Rust and expose that.
- FlyingSnake 6y ago
  Swift got stable ABI in version 5, that’s bit late IMO. Also the community efforts to improve Rust interop (e.g. Rustler/Elixer) are way ahead when compared to Swift. That being said, I personally am happy that both languages to have first class FFI
  - skohan 6y ago
    > that’s bit late IMO It's pretty rare for a language to have a stable ABI, no? I mean Rust still doesn't have one.
rvz 6y ago
Well for creating bindings, Rust's bindgen falls short. The fact that you need to play around and switch on flags to properly recognise variables, macros and functions over a .h only for generating the FFI layer, it is just harder to maintain, even when updating the library. Swift's ClangImporter does this automatically in the language via clang modules, unlike Rust's bindgen.

skohan 6y ago

> disregard for other platforms (Linux/Windows are very much second/third class citizens) It's worth noting that improved and cross-platform support is a stated priority for the next Swift version. It's already quite usable on Ubuntu, and Windows and other Linux distros beyond Ubuntu have been added to the CI pipeline for Swift development.