3 ms·

The quality of implementation of the Swift compiler is in no way comparable to Rust's. It's super easy to cause its type check to timeout, which is something I

by ii41 3y ago

The quality of implementation of the Swift compiler is in no way comparable to Rust's. It's super easy to cause its type check to timeout, which is something I haven't seen when using Rust. I even managed to make it crash several times. It also lacks some pretty standard features such as turning off warnings of a certain type or on a certain line. The language itself is quite problematic when compared to Rust, too. For instance, Swift doesn't have the orphan rule, so it's possible that 2 packages implement the same protocol for the same type, and when this happens currently there are no solutions; there is this strange design decision that classes and structs should be different things and each have their own set of random limitations; and there is SwiftUI, which hacks on the syntax itself, making statements no longer mean what they are supposed to mean.

slavapestov 3y ago
> It's super easy to cause its type check to timeout, which is something I haven't seen when using Rust. Yeah, the operator overloading design makes it too easy to construct an exponential search space. > For instance, Swift doesn't have the orphan rule, so it's possible that 2 packages implement the same protocol for the same type, and when this happens currently there are no solutions; There's now a warning about this: https://github.com/apple/swift-evolution/blob/main/proposals/0364-retroactive-conformance-warning.md https://github.com/apple/swift-evolution/blob/main/proposals.... What other solutions can there be other than making it a hard error? It seems like an inherent drawback of typeclasses over first-class modules. > there is this strange design decision that classes and structs should be different things and each have their own set of random limitations structs in Swift are the same as structs in Rust, and a class is a heap-allocated reference counted box, like an Arc<Box<T>>. What are the random limitations? As far as I'm aware the behavioral differences between structs and classes are entirely explainable by the above. > and there is SwiftUI, which hacks on the syntax itself, making statements no longer mean what they are supposed to mean Result builders are a language feature and not part of SwiftUI: https://github.com/apple/swift-evolution/blob/main/proposals/0289-result-builders.md https://github.com/apple/swift-evolution/blob/main/proposals...
- ii41 3y ago
  > structs in Swift are the same as structs in Rust, and a class is a heap-allocated reference counted box, like an Arc<Box<T>>. Yeah, and by representing the differences this way, Rust allows you to easily decide whether an object is used directly or is wrapped in a rc box when its used, instead of when it's defined, often not by you, and when you change your mind you don't need to change all methods or functions than mutates it and all their call sites. > Result builders are a language feature and not part of SwiftUI I admit that this is the first time I see the term result builders. This is never mentioned in any SwiftUI documentation I've seen, so I guess I should extend my complaint to include quality of docs :p. Whatever this is called you seem to agree that the syntax is hacked and it can get hard to understand what something means
  - slavapestov 3y ago
    > Yeah, and by representing the differences this way, Rust allows you to easily decide whether an object is used directly or is wrapped in a rc box when its used, instead of when it's defined, often not by you, and when you change your mind you don't need to change all methods or functions than mutates it and all their call sites Changing a value type into a reference type is a pretty fundamental transformation because your local mutations now become non-local. Its not clear the Rust approach makes this any easier either, since you’d still have to update all call sites that perform mutation if suddenly one of your value types was now always wrapped in a box. > Whatever this is called you seem to agree that the syntax is hacked and it can get hard to understand what something means Result builders are just a way to build data types from the results of top-level expressions (hence their name). It’s not just a SwiftUI thing, they’re also used for regular expressions for example: https://github.com/apple/swift-evolution/blob/main/proposals/0351-regex-builder.md https://github.com/apple/swift-evolution/blob/main/proposals...
    - plorkyeran 3y ago
      The regex result builder is awful. It's very obviously a feature which was developed to make SwiftUI look good in WWDC presentations at the expense of everything else, and no one's found anything that they're actually useful for even with some effort to pretend that it's not just there for SwiftUI.

by ii41 3y ago

slavapestov 3y ago

> It's super easy to cause its type check to timeout, which is something I haven't seen when using Rust. Yeah, the operator overloading design makes it too easy to construct an exponential search space. > For instance, Swift doesn't have the orphan rule, so it's possible that 2 packages implement the same protocol for the same type, and when this happens currently there are no solutions; There's now a warning about this: https://github.com/apple/swift-evolution/blob/main/proposals/0364-retroactive-conformance-warning.md https://github.com/apple/swift-evolution/blob/main/proposals.... What other solutions can there be other than making it a hard error? It seems like an inherent drawback of typeclasses over first-class modules. > there is this strange design decision that classes and structs should be different things and each have their own set of random limitations structs in Swift are the same as structs in Rust, and a class is a heap-allocated reference counted box, like an Arc<Box<T>>. What are the random limitations? As far as I'm aware the behavioral differences between structs and classes are entirely explainable by the above. > and there is SwiftUI, which hacks on the syntax itself, making statements no longer mean what they are supposed to mean Result builders are a language feature and not part of SwiftUI: https://github.com/apple/swift-evolution/blob/main/proposals/0289-result-builders.md https://github.com/apple/swift-evolution/blob/main/proposals...

ii41 3y ago
> structs in Swift are the same as structs in Rust, and a class is a heap-allocated reference counted box, like an Arc<Box<T>>. Yeah, and by representing the differences this way, Rust allows you to easily decide whether an object is used directly or is wrapped in a rc box when its used, instead of when it's defined, often not by you, and when you change your mind you don't need to change all methods or functions than mutates it and all their call sites. > Result builders are a language feature and not part of SwiftUI I admit that this is the first time I see the term result builders. This is never mentioned in any SwiftUI documentation I've seen, so I guess I should extend my complaint to include quality of docs :p. Whatever this is called you seem to agree that the syntax is hacked and it can get hard to understand what something means
- slavapestov 3y ago
  > Yeah, and by representing the differences this way, Rust allows you to easily decide whether an object is used directly or is wrapped in a rc box when its used, instead of when it's defined, often not by you, and when you change your mind you don't need to change all methods or functions than mutates it and all their call sites Changing a value type into a reference type is a pretty fundamental transformation because your local mutations now become non-local. Its not clear the Rust approach makes this any easier either, since you’d still have to update all call sites that perform mutation if suddenly one of your value types was now always wrapped in a box. > Whatever this is called you seem to agree that the syntax is hacked and it can get hard to understand what something means Result builders are just a way to build data types from the results of top-level expressions (hence their name). It’s not just a SwiftUI thing, they’re also used for regular expressions for example: https://github.com/apple/swift-evolution/blob/main/proposals/0351-regex-builder.md https://github.com/apple/swift-evolution/blob/main/proposals...
  - plorkyeran 3y ago
    The regex result builder is awful. It's very obviously a feature which was developed to make SwiftUI look good in WWDC presentations at the expense of everything else, and no one's found anything that they're actually useful for even with some effort to pretend that it's not just there for SwiftUI.