5 ms·

Personally, I think that Rust is a way better language from a design point of view, but if you want to make a living, then Go and Swift are better.

by est31 6y ago

jb1991 6y ago
Rust is also a much bigger investment for the developer to learn and master. Much of the beauty of Rust is in Swift -- heck, the same language designers have worked in both languages.
- pjmlp 6y ago
  Much of the beauty of ML is in Rust and Swift.
  - TurboHaskal 6y ago
    To some degree, yes. Until you try to write what would be idiomatic SML code in those and the lack of tracing GC comes to bite you. Nevertheless, I guess it's good sum types are making it into the mainstream.
    - pjmlp 6y ago
      Agreed, that is also a reason why I think in the end GC by default (regardless of the algorithm) + affine types will win adoption across mainstream languages, and pure affine type languages like Rust will find their niche on scenarios like those where certifications like MISRA are required, or kernel stuff.
- est31 6y ago
  You mean Graydon moving from Rust to Swift? On Rust he had a tremendous influence, but while he was on the team, I'm not sure about his influence on Swift. I think Swift is more constrained, having to have good compatibility with objective C. Rust is only compatible with C, and thus has more freedom to do away with decisions that turned out to be bad. Edit: probably Gankra too. IIRC she had an internship at mozilla designing important parts of the Rust standard library then later went to work at Apple.
deleted 6y ago
[deleted]
user-the-name 6y ago
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.
cute_boi 6y ago
I don't know why he is being downvoted but I agree here. Rust is a novel lang. Its a general purpose lang unlike swift which is made specifically for Apple ecosystem. Just because apple made a swift doesn't mean its design is better.
- jamil7 6y ago
  I didn't downvote. But I think the downvotes are because it apprently isn't possible on HN to have a discussion about any language without Rust evangelists appearing. We get it, it's great and deserves it's praise but doesn't need to be mentioned everywhere. The topic also had nothing to do with language design.
- mrtksn 6y ago
  I downvoted because it is needlessly hostile without adding anything to the discussion. The topic here is that Swift developers made a release of an open source software and it is not if Swift is the best or if Rust is better. Why would you try to steer it in that direction? It's like having your friend serving you his Lasagne that worked on and is pride of, then have someone in the group saying that Brussels sprouts is a better meal but we are going to eat this because most people don't care enough about their health or don't know better. Don't be that person if you want to be likeable.
  - est31 6y ago
    Almost all top comments in this thread are evaluating the Swift language instead of the library: * https://news.ycombinator.com/item?id=25158147 https://news.ycombinator.com/item?id=25158147 spends 530 characters on their past programming life and an evaluation of the Swift language, and only then ends the comment with "I'll definitely check this one out." * https://news.ycombinator.com/item?id=25157942 https://news.ycombinator.com/item?id=25157942 mostly talks about the language as well instead of this ssh library. It's a bit more on topic though as it talks about swift on the server, which this library can belong to (but doesn't have to, the library also has a ssh client part). Still, way offtopic if you are strict. * https://news.ycombinator.com/item?id=25158932 https://news.ycombinator.com/item?id=25158932 alright so this comment is actually about the SSH library. Only barely has any replies though. Apparently hn'ers don't like to talk about the ssh library. * And there is my comment https://news.ycombinator.com/item?id=25158334 https://news.ycombinator.com/item?id=25158334 which as of now has the most discussion, but it's downvoted at a -4 score ATM. I actually came to this thread where these responses were the top replies (except for the single one which is actually on-topic, it wasn't present yet). So I thought I'd add my own. Also it's sad how nobody replied to the second part of my post. I think that employability is a clear benefit of Swift and Go over Rust. If I check indeed Germany for "Swift Software", I get 596 results. If I check "Go Software" I get 2463 jobs. Checking "Rust Software" gives me 131 results. A big difference.

Personally, I think that Rust is a way better language from a design point of view, but if you want to make a living, then Go and Swift are better.

by est31 6y ago

Personally, I think that Rust is a way better language from a design point of view, but if you want to make a living, then Go and Swift are better.

jb1991 6y ago

Rust is also a much bigger investment for the developer to learn and master. Much of the beauty of Rust is in Swift -- heck, the same language designers have worked in both languages.

pjmlp 6y ago
Much of the beauty of ML is in Rust and Swift.
- TurboHaskal 6y ago
  To some degree, yes. Until you try to write what would be idiomatic SML code in those and the lack of tracing GC comes to bite you. Nevertheless, I guess it's good sum types are making it into the mainstream.
  - pjmlp 6y ago
    Agreed, that is also a reason why I think in the end GC by default (regardless of the algorithm) + affine types will win adoption across mainstream languages, and pure affine type languages like Rust will find their niche on scenarios like those where certifications like MISRA are required, or kernel stuff.
est31 6y ago
You mean Graydon moving from Rust to Swift? On Rust he had a tremendous influence, but while he was on the team, I'm not sure about his influence on Swift. I think Swift is more constrained, having to have good compatibility with objective C. Rust is only compatible with C, and thus has more freedom to do away with decisions that turned out to be bad. Edit: probably Gankra too. IIRC she had an internship at mozilla designing important parts of the Rust standard library then later went to work at Apple.

deleted 6y ago

[deleted]

user-the-name 6y ago

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.

cute_boi 6y ago

I don't know why he is being downvoted but I agree here. Rust is a novel lang. Its a general purpose lang unlike swift which is made specifically for Apple ecosystem. Just because apple made a swift doesn't mean its design is better.

jamil7 6y ago
I didn't downvote. But I think the downvotes are because it apprently isn't possible on HN to have a discussion about any language without Rust evangelists appearing. We get it, it's great and deserves it's praise but doesn't need to be mentioned everywhere. The topic also had nothing to do with language design.
mrtksn 6y ago
I downvoted because it is needlessly hostile without adding anything to the discussion. The topic here is that Swift developers made a release of an open source software and it is not if Swift is the best or if Rust is better. Why would you try to steer it in that direction? It's like having your friend serving you his Lasagne that worked on and is pride of, then have someone in the group saying that Brussels sprouts is a better meal but we are going to eat this because most people don't care enough about their health or don't know better. Don't be that person if you want to be likeable.
- est31 6y ago
  Almost all top comments in this thread are evaluating the Swift language instead of the library: * https://news.ycombinator.com/item?id=25158147 https://news.ycombinator.com/item?id=25158147 spends 530 characters on their past programming life and an evaluation of the Swift language, and only then ends the comment with "I'll definitely check this one out." * https://news.ycombinator.com/item?id=25157942 https://news.ycombinator.com/item?id=25157942 mostly talks about the language as well instead of this ssh library. It's a bit more on topic though as it talks about swift on the server, which this library can belong to (but doesn't have to, the library also has a ssh client part). Still, way offtopic if you are strict. * https://news.ycombinator.com/item?id=25158932 https://news.ycombinator.com/item?id=25158932 alright so this comment is actually about the SSH library. Only barely has any replies though. Apparently hn'ers don't like to talk about the ssh library. * And there is my comment https://news.ycombinator.com/item?id=25158334 https://news.ycombinator.com/item?id=25158334 which as of now has the most discussion, but it's downvoted at a -4 score ATM. I actually came to this thread where these responses were the top replies (except for the single one which is actually on-topic, it wasn't present yet). So I thought I'd add my own. Also it's sad how nobody replied to the second part of my post. I think that employability is a clear benefit of Swift and Go over Rust. If I check indeed Germany for "Swift Software", I get 596 results. If I check "Go Software" I get 2463 jobs. Checking "Rust Software" gives me 131 results. A big difference.