Both of Swift and Rust are good tools and have pros and cons. The problem is I have to focus on one stuff more because I don’t have infinite resources. Therefore I need to speculate some future.
Convergent Evolution
Language evolves. In a long term future, Swift will get unique ownership, move semantic, memory layout support. Rust will develop more convenience and tool support. At last, both of them will evolve convergely. But the passage to get there will be very different.
Focused Evolution
The difference comes from passages. Resources are limited. Developers should set priority and focus on small number of goals. Usually those goals set to immediate needs of resource providers, therefore, direction of evolution is determined by who support the resources.
- Swift is mainly supported by Apple. Community support is very weak.
- Rust is mainly supported by Mozilla. Community support is very strong.
Swift’s major supporter is Apple. Apple’s immediate problem is providing better development environment for their platforms. Swift also promises better support for non-Apple platforms, but with far less priority. Apple wanted a better Objective-C and don’t have to replace their C++ code in thier low level now. This makes Swift’s top priority is better support for Apple’s UI app development. Objective-C interoperability, better syntax, IDE support, DSL support is more important for them. Memory layout is not really a big deal for UI app development. Apple Swift team woule spend far more time to implement smoother Objective-C or existing Apple framework inter-op support rather than borrow checker.
Rust’s major supporter is Mozilla. Mozilla’s immediate problem is productivity. They’re sick of extreme low productivity of C++, and want to replace C++ immediately. Nowadays web browsers are like OS. Developing a web browser needs OS development level feature support. They needs memory layout control, serialization, real-time support, zero abstraction, move semantics, static cross-thread safety right now. That’s why Rust provides such features now not later.
One Example: Serialization
One example is serialization support. Rust tried several times to provide serialization, and finally they got serde. serde is based on static code generation and can encode every value trees in Rust including sum-types (enums with parametric values) with a few lines of code. Even further, serde is not a compiler magic. It’s plain macro just like any other code you wrote. If you’re not satisfied with serde, you are free to implement your own.
Swift’s corresponding provision is Codable. Surprisingly, it cannot encode/decode sum-types from first. Maybe eventually it can, but no one knows when because its priority is far behind other stuffs like data-binding or key-path support. Even worse, Codable still needs far more complicated code such as CodingKey shits to control serialization properly. Also Codable is a complete compiler magic and there’s no way to make it better unless you build your own compiler. And involving into Swift compiler development needs you to be an expert C++ programmer. If you want to make Swift better, you need to code in C++. This is awful, but not really a problem to Apple as they have near infinite amount of money to hire people to deal with any shits. But I am not Apple. What I have is only my personal time, and I don’t want to waste my life to write repeated sum-type decoding or cryptic C++ errors.
Another Example: Web Browser App Support
Another example is web browser app support. Both of Swift and Rust are LLVM family, and can be compiled into WASM. Here Rust already have some level of web browser target support, but Swift does not.
I am not claiming Apple would hate Swift on web browsers. Swift on web browsers actually adds more values to Swift language, and actually can be helpful for Apple. But, Apple has no reason to prioritize it. Apple needs to support their platform first. And browsers… well, maybe later.
Scripting vs. Optimization
So far I observed, Swift is designed and getting developed to be an app scripting language. Unlike other scripting languages, Swift potentially can support more lower level operations, but I think it’ll be painful to use such low level features even if they implement it because Swift focused for higher level apps. I think Swift is aiming position of Python, and it’ll be great if I can replace Python with Swift script.
Rust focuses to replace C++. Rust sacrifices convenience for performance and predictability.
Interoperation
Ideal situation would be having high level of inter-operation. Write Rust code for number crunching simulation, and write Swift code to control them. If Swift add unique ownership and move semantics, this will be more feasible.
For me, the ideal strategy would be focusing on Rust first. And wait for Swift to implement move semantics and unique ownership. After that, making them play well would be far more easier, and maybe we can intermix them natively.
I hope I can do it at someday.
