3 ms·
Curious what Rustians think about this, and if this is a key piece missing to becoming a better systems language.
by azinman2 5y ago
Curious what Rustians think about this, and if this is a key piece missing to becoming a better systems language.
- worik 5y agoSwift is a long way from Rust There is no memory model, really, from the POV of a Swift programmer. There are no guarantees about the cost of abstractions. The threading model is awful. Almost useless. I works well for simple cases (which are simple!) and not at all for complex cases. There must be a way for threads to communicate and synchronise other than a semaphore, but I have not found it. (Do not need it - keeping it simple and on one thread). The compiler is very slow. You thought the Rust compiler was slow? Try Swift! Not Swift, but the IDE provided by Apple cannot deal well with programmes when they approach ~100k lines. It gets very slow and its tools become unreliable. The learning curve of Rust makes it unsuitable for general purpose computing, and there is nothing hard about learning Swift. It has a lot of modern features (c/f C, my first love!) - map, reduce, optionals, result types, generics.... I do not think it is a threat to Rust for system programming outside of Apple (Dog knows what madness they will try). I think it's main competitor is Go. Not in systems programming but in general purpose computing.
- rtoway 5y agoSwift tooling is surprisingly bad especially when It's made by a trillion dollar company. Rust's free rust-analyzer extension provides much faster and much more feature filled IDE features than XCode.
- pornel 5y agoSwift's normal syntax is very nice and clean compared to Rust that needs to add ownership-related details. OTOH the way Swift proposes to add ownership-related syntax is obviously a retrofit, and looks verbose. Rust had a syntax designed for ownership from the start. Swift needs extra syntax to first undo the ARC defaults, and then syntax to control the ownership. In this regard, Swift looks noisier. Swift's `@nonescaping String` is `&str` in Rust. Swift's `arg: consuming Foo` is simply `arg: Foo` in Rust. Swift's `x = move(y)` is `x = y` in Rust. From the point of view of semantics and functionality, it's all good. Swift's interaction with C was dangerous due to unobvious implicit rules of ARC. Having ability to get compiler-checked guarantees for lifetimes is very helpful.
- pjmlp 5y agoFrom the point of view of language geek, I prefer Swift's approach, as it is closer to PL/I, ALGOL and Wirth's linage of languages. High level constructs for being productive without stepping too much, while offering the language features to go downlevel as much as required, when it is time to actually do it. Naturally this matters mostly to those invested into the Apple's ecosystem.
- Zababa 5y ago> From the point of view of language geek, I prefer Swift's approach, as it is closer to PL/I, ALGOL and Wirth's linage of languages. That's surprising, I remember that one of the specificities of Pascal and its descendants are its very fast compilation time. Swift seems to be at the exact opposite end of that spectrum. I'm not sure if it's the type inference, the frontend, LLVM or something else though.
- pjmlp 5y agoI would say a mix of LLVM and type inference play a big role.
- mamcx 5y agoI like Swift a lot, and if Apple were smarter and support linux/windows/android i will not move to Rust. But swift have a lot of "magic". The major advantage of Rust, the biggest one for a system language, is how explicit is about almost everything. Is incredible how much you can know just looking at the code at hand.