4 ms·

Rust is more advanced, but there is more to language design than technical cleverness. Swift is miles ahead of Rust in terms of language usability and ergonomi

Rust is more advanced, but there is more to language design than technical cleverness. Swift is miles ahead of Rust in terms of language usability and ergonomics.

est31 6y ago
You have any concrete examples? I'm not very familiar with swift, so I opened a random file in the project [0]. On the first glance it feels like the typical noisy OOP java code base. Probably most of it done with automated tools. Very weird were the named arguments repeating the same thing [1]. Would have been much shorter in Rust as it doesn't have named arguments (and IMO Rust should never get them). And on the first half of the file there are a bunch of POD struct definitions with a few init functions. In Rust, those POD structs where all members are public can be easily be initialized without having to create functions for it (but then you do have to name the "arguments", but for struct initializers I don't consider it to be a problem). So way less repetition. [0]: https://github.com/apple/swift-nio-ssh/blob/main/Sources/NIOSSH/Child%20Channels/ChildChannelUserEvents.swift https://github.com/apple/swift-nio-ssh/blob/main/Sources/NIO... [1]: https://github.com/apple/swift-nio-ssh/blob/8a75ab90e1b12182e3ac8737590e4f9710f2f11f/Sources/NIOSSH/Child%20Channels/ChildChannelUserEvents.swift#L358 https://github.com/apple/swift-nio-ssh/blob/8a75ab90e1b12182...
- user-the-name 6y ago
  Named arguments is a HUGE thing for ergonomics. It makes code many times more readable, since it automatically documents intent much more clearly. The code linked here is nowhere near representative of regular Swift code. As a very basic made-up example, the real value of named arguments is code like this: FileManager.copy(path1, path2) What does that do? There is no way to tell which file is copied to which. In Swift, this is written as: FileManager.copy(from: path1, to: path2) Suddenly, there is no need to look up the function to figure out what it does. It is perfectly clear.
  - todd8 6y ago
    The first use I recall for named parameters was in Algol60. One could write: copyfile(path1)to:(path2) Instead of: copyfile(path1, path2) I always liked that idea, but found Objective-C’s version of this less attractive. Smalltalk had named parameters too. Algol60, to me, had the nicest syntax for this.
    - user-the-name 6y ago
      Swift has improved nicely on the Objective-C style, I think.
  - ChrisMarshallNY 6y ago
    If you were being "idiomatic," you'd probably write it like so: MyOwnFileManager.copyFileFrom(_ path1: String, to path2: String) Apple has started to make it like that.
    - user-the-name 6y ago
      No, that is the old Objective-C style. It is definitely not idiomatic.
      - ChrisMarshallNY 6y ago
        In the more recent Swift and library releases, I have had to change my code to fit the above pattern, as I get deprecation errors all the time. But you are correct that it started with ObjC. That doesn't make it a bad thing. It seems that Apple is starting to circle back. I prefer the initial one that you posited. I'm pretty sure the Swift style guide suggests the way you mentioned, and not the ObjC way. BTW: I deleted the post where I talk about where I saw this. It seems folks just want to argue, and that's not why I come here.
        user-the-name 6y ago
        I've not seen any of these in years now. Where have they been popping up?
- jurip 6y ago
  "Typical noisy OOP java code base", without a single class in the whole file, only value types. As for automated tools, I think you're giving Xcode too much credit. It'll help you a bit, but not much.
- yoz-y 6y ago
  > and IMO Rust should never get them I guess whatever floats your boat. Personally, I enjoy not having to write functions like doStuff(true, true, true, false) or alternatively define types for every single boolean flag I want to have. Terseness is a non goal for Swift. > And on the first half of the file there are a bunch of POD struct definitions with a few init functions. I don't know how rust handles this but in swift, each POD struct has an implicit member wise constructor visible from the file it's defined. This is for encapsulation purposes, as its signature of course changes if you add fields to the struct.
  - est31 6y ago
    > Personally, I enjoy not having to write functions like doStuff(true, true, true, false) Yeah that's not beautiful, but most of my code is rather doStuff(foo, bar, baz) where foo, bar and baz are descriptive variable names. I agree that it's hard to understand with literals, but in the rare cases you need such flags you can either have a config struct or use the builder pattern. Also, nowadays you can set up vscode to use the rust-analyzer LSP plugin, which shows you the types as well as the parameter names. But of course that doesn't work on Github and similar places. IDK in general, the people who want named arguments outnumber the people who don't want them, at least in threads about the question, which obviously preselects the people who want them. Maybe eventually Rust will get them, no idea. But IMO that code shows how named arguments can make code more noisy than before. > I don't know how rust handles this but in swift, each POD struct has an implicit member wise constructor visible from the file it's defined. This is for encapsulation purposes, as its signature of course changes if you add fields to the struct. In Rust, POD structs can be constructed iff all their members are visible through the publicity system to the code that tries to construct them. If it's in a different crate, it's also important whether there is a #[non_exhaustive] attribute on the struct declaration or not.
    - user-the-name 6y ago
      > where foo, bar and baz are descriptive variable names But descriptive variable names should describe what those variables ARE, not how they are going to be passed to a function. So, does copy(tempFile, databaseFile) copy the temporary file over the database file, or vice versa?
cute_boi 6y ago
Miles ahead? This is problem with hackernews? Where is proof? How is Swift miles ahead than Rust? Before claiming anything please give us proof? Putting Arc everywhere doesn't make lang miles ahead.
- user-the-name 6y ago
  Arc is a technical feature, not ergonomics. Ergonomics is things like the optional handling syntax in Swift, or named arguments.
  - cute_boi 6y ago
    So just for three thing you claimed "Swift is miles ahead of Rust in terms of language usability and ergonomics." Wow. Now let me tell you Why Rust is miles ahead than Swift. 1. Swift abstract away lot of memory management by defaulting to thread safe reference counting. In Rust you are free to use stack, heap and wide range of other option. Rust has a freedom here. ARC is basically a garbage collection whatever apple say. 2. Rust pattern matching is novel. You can see match on csharp, php because its so good. 3. Rust is far better in concurrency world. 4. Cross Platform support is Meh in Swift. Its starting but its too far. If you are writing ios app or anything for mac yes swift is ahead. But in other field Rust is far ahead. See the link for fair comparison. I have used various PL in my life time from c, c++ , java, swift , rust etc. And I am not biased towards rust. But simply saying swift is miles ahead is totally unfair to me. https://v4.chriskrycho.com/rust-and-swift.html https://v4.chriskrycho.com/rust-and-swift.html
    - oscargrouch 6y ago
      He/She was talking about developer ergonomics. And in that particular sense, while i have programmed in Swift and Rust, i completely agree with him/her. In your disagreement you are pointing out how you think Rust is more _advanced_ than Swift. But this goes into a tangential topic, that was not what the parent was pointing out. In developer productivity and ergonomics Rust is not far away from C++, and Swift is more akin to Kotlin, C# and Java, but it feels a little better like Typescript or Dart. I wonder, why, so many times, Rust folks (Why to get tied to a tech, i also don't get it) gets so hostile and arrogant about the language, and to be fair this is some of the reasons i keep a certain distance from it, and i can imagine that im not the only one.

Rust is more advanced, but there is more to language design than technical cleverness. Swift is miles ahead of Rust in terms of language usability and ergonomics.

est31 6y ago

You have any concrete examples? I'm not very familiar with swift, so I opened a random file in the project [0]. On the first glance it feels like the typical noisy OOP java code base. Probably most of it done with automated tools. Very weird were the named arguments repeating the same thing [1]. Would have been much shorter in Rust as it doesn't have named arguments (and IMO Rust should never get them). And on the first half of the file there are a bunch of POD struct definitions with a few init functions. In Rust, those POD structs where all members are public can be easily be initialized without having to create functions for it (but then you do have to name the "arguments", but for struct initializers I don't consider it to be a problem). So way less repetition. [0]: https://github.com/apple/swift-nio-ssh/blob/main/Sources/NIOSSH/Child%20Channels/ChildChannelUserEvents.swift https://github.com/apple/swift-nio-ssh/blob/main/Sources/NIO... [1]: https://github.com/apple/swift-nio-ssh/blob/8a75ab90e1b12182e3ac8737590e4f9710f2f11f/Sources/NIOSSH/Child%20Channels/ChildChannelUserEvents.swift#L358 https://github.com/apple/swift-nio-ssh/blob/8a75ab90e1b12182...

user-the-name 6y ago
Named arguments is a HUGE thing for ergonomics. It makes code many times more readable, since it automatically documents intent much more clearly. The code linked here is nowhere near representative of regular Swift code. As a very basic made-up example, the real value of named arguments is code like this: FileManager.copy(path1, path2) What does that do? There is no way to tell which file is copied to which. In Swift, this is written as: FileManager.copy(from: path1, to: path2) Suddenly, there is no need to look up the function to figure out what it does. It is perfectly clear.
- todd8 6y ago
  The first use I recall for named parameters was in Algol60. One could write: copyfile(path1)to:(path2) Instead of: copyfile(path1, path2) I always liked that idea, but found Objective-C’s version of this less attractive. Smalltalk had named parameters too. Algol60, to me, had the nicest syntax for this.
  - user-the-name 6y ago
    Swift has improved nicely on the Objective-C style, I think.
- ChrisMarshallNY 6y ago
  If you were being "idiomatic," you'd probably write it like so: MyOwnFileManager.copyFileFrom(_ path1: String, to path2: String) Apple has started to make it like that.
  - user-the-name 6y ago
    No, that is the old Objective-C style. It is definitely not idiomatic.
    - ChrisMarshallNY 6y ago
      In the more recent Swift and library releases, I have had to change my code to fit the above pattern, as I get deprecation errors all the time. But you are correct that it started with ObjC. That doesn't make it a bad thing. It seems that Apple is starting to circle back. I prefer the initial one that you posited. I'm pretty sure the Swift style guide suggests the way you mentioned, and not the ObjC way. BTW: I deleted the post where I talk about where I saw this. It seems folks just want to argue, and that's not why I come here.
      - user-the-name 6y ago
        I've not seen any of these in years now. Where have they been popping up?
jurip 6y ago
"Typical noisy OOP java code base", without a single class in the whole file, only value types. As for automated tools, I think you're giving Xcode too much credit. It'll help you a bit, but not much.
yoz-y 6y ago
> and IMO Rust should never get them I guess whatever floats your boat. Personally, I enjoy not having to write functions like doStuff(true, true, true, false) or alternatively define types for every single boolean flag I want to have. Terseness is a non goal for Swift. > And on the first half of the file there are a bunch of POD struct definitions with a few init functions. I don't know how rust handles this but in swift, each POD struct has an implicit member wise constructor visible from the file it's defined. This is for encapsulation purposes, as its signature of course changes if you add fields to the struct.
- est31 6y ago
  > Personally, I enjoy not having to write functions like doStuff(true, true, true, false) Yeah that's not beautiful, but most of my code is rather doStuff(foo, bar, baz) where foo, bar and baz are descriptive variable names. I agree that it's hard to understand with literals, but in the rare cases you need such flags you can either have a config struct or use the builder pattern. Also, nowadays you can set up vscode to use the rust-analyzer LSP plugin, which shows you the types as well as the parameter names. But of course that doesn't work on Github and similar places. IDK in general, the people who want named arguments outnumber the people who don't want them, at least in threads about the question, which obviously preselects the people who want them. Maybe eventually Rust will get them, no idea. But IMO that code shows how named arguments can make code more noisy than before. > I don't know how rust handles this but in swift, each POD struct has an implicit member wise constructor visible from the file it's defined. This is for encapsulation purposes, as its signature of course changes if you add fields to the struct. In Rust, POD structs can be constructed iff all their members are visible through the publicity system to the code that tries to construct them. If it's in a different crate, it's also important whether there is a #[non_exhaustive] attribute on the struct declaration or not.
  - user-the-name 6y ago
    > where foo, bar and baz are descriptive variable names But descriptive variable names should describe what those variables ARE, not how they are going to be passed to a function. So, does copy(tempFile, databaseFile) copy the temporary file over the database file, or vice versa?

cute_boi 6y ago

Miles ahead? This is problem with hackernews? Where is proof? How is Swift miles ahead than Rust? Before claiming anything please give us proof? Putting Arc everywhere doesn't make lang miles ahead.

user-the-name 6y ago
Arc is a technical feature, not ergonomics. Ergonomics is things like the optional handling syntax in Swift, or named arguments.
- cute_boi 6y ago
  So just for three thing you claimed "Swift is miles ahead of Rust in terms of language usability and ergonomics." Wow. Now let me tell you Why Rust is miles ahead than Swift. 1. Swift abstract away lot of memory management by defaulting to thread safe reference counting. In Rust you are free to use stack, heap and wide range of other option. Rust has a freedom here. ARC is basically a garbage collection whatever apple say. 2. Rust pattern matching is novel. You can see match on csharp, php because its so good. 3. Rust is far better in concurrency world. 4. Cross Platform support is Meh in Swift. Its starting but its too far. If you are writing ios app or anything for mac yes swift is ahead. But in other field Rust is far ahead. See the link for fair comparison. I have used various PL in my life time from c, c++ , java, swift , rust etc. And I am not biased towards rust. But simply saying swift is miles ahead is totally unfair to me. https://v4.chriskrycho.com/rust-and-swift.html https://v4.chriskrycho.com/rust-and-swift.html
  - oscargrouch 6y ago
    He/She was talking about developer ergonomics. And in that particular sense, while i have programmed in Swift and Rust, i completely agree with him/her. In your disagreement you are pointing out how you think Rust is more _advanced_ than Swift. But this goes into a tangential topic, that was not what the parent was pointing out. In developer productivity and ergonomics Rust is not far away from C++, and Swift is more akin to Kotlin, C# and Java, but it feels a little better like Typescript or Dart. I wonder, why, so many times, Rust folks (Why to get tied to a tech, i also don't get it) gets so hostile and arrogant about the language, and to be fair this is some of the reasons i keep a certain distance from it, and i can imagine that im not the only one.