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.
Nevertheless, I guess it's good sum types are making it into the mainstream.
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.
Swift is miles ahead of Rust in terms of language usability and ergonomics.
[0]: https://github.com/apple/swift-nio-ssh/blob/main/Sources/NIO...
[1]: https://github.com/apple/swift-nio-ssh/blob/8a75ab90e1b12182...
As a very basic made-up example, the real value of named arguments is code like this:
FileManager.copy(path1, path2)
FileManager.copy(from: path1, to: path2)
copyfile(path1)to:(path2)
copyfile(path1, path2)
MyOwnFileManager.copyFileFrom(_ path1: String, to path2: String)
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.
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.
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.
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?
Ergonomics is things like the optional handling syntax in Swift, or named arguments.
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.
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.
It's honestly crossed over from being a meme (rewrite it in Rust) into becoming obnoxious. Obviously a small, vocal minority as always.
They are both forms of automatic memory management but that is about it.
There is nothing novel about pattern matching in rust, swift has pattern matching too, and both languages inherited it from Ocaml, and the ml family of languages in general.
Just because apple made a swift doesn't mean its design is better.
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.
* 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 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 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 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.
Talking about Swift is not irrelevant as it is a prerequisite to use the software in question.
I guess If you have replied to someone asking if Swift or something else is worth learning, I would have upvoted you.
The way it is just feels spammy.