What are the distinctive features of Rust that Swift has that aren't in some way derived from ObjC? (I'm sure there are some; I just don't know Rust.)
To name a few: safety enforced at compile-time without any sort of GC/ARC (probably the biggest), more precise control over the hardware (e.g. more concrete pointers), the lack of a required runtime -- basically it has much better support for low-level features while not sacrificing many high-level features.
Swift – observations from Rust’s original designer
41–50 of 88 posts
Re: Swift – observations from Rust’s original designer
#42But hey, any opportunity to pimp your favorite language is fair.
Re: Swift – observations from Rust’s original designer
#43Re: Swift – observations from Rust’s original designer
#44Earlier quoted context omitted.
To name a few: safety enforced at compile-time without any sort of GC/ARC (probably the biggest), more precise control over the hardware (e.g. more concrete pointers), the lack of a required runtime -- basically it has much better support for low-level features while not sacrificing many high-level features.
I believe tptacek was asking for the intersection of features between Swift and Rust, not for features that Rust has but Swift doesn't (like compile-time memory safety without GC/ARC).
Why couldn't he have just have written "(Swift ∖ ObjC) ∩ Rust"? :)
Re: Swift – observations from Rust’s original designer
#45I hope ideas will flow the other way too, and Rust adopts some sugar from Swift. I find `if let concrete = optional` sooo much nicer than `match optional { (concrete) => , _ => {} }`. Rust has solid semantics that covers more than Swift. OTOH Apple has put their UX magic into the language's syntax. Some syntax shortcuts, like `.ShortEnumWhenInContext` are delightful. The two combined will be the perfect language ;)
Re: Swift – observations from Rust’s original designer
#46I think the author is seeing a little more than there actually is. There is a lot more overlap between Swift and C#/Java than with Rust. Actually, I see very little Rust in Swift, except for very trivial features that are present in 90% of C-based languages. But hey, any opportunity to pimp your favorite language is fair.
It seems to borrow quite extensively C# and .. I don't know how to say this politely or immodestly ... Rust. Which is flattering if true! Of course I'm biased. Also a language pluralist, and since Rust is a major cobbling-together of things we liked in other languages (ML, C++, C#, Lisp, Ruby, etc.)
It also seems like he's more generally excited about the prospects of not being limited to a small set of languages to do powerful things. "It's remarkable to me that in the years between, we've seen such a shift in what's considered "normal" new-language tech. F# is shipping on several platforms (whether or not M# ever actually surfaces again); Scala is considered an employable skill; C++11 has lambdas and local type inference at least, if not algebraic types or pattern matching; Rust actually exists now; and now one can rely on similar comforts in the Apple ecosystem. How delightful!"Re: Swift – observations from Rust’s original designer
#47Re: Swift – observations from Rust’s original designer
#48Earlier quoted context omitted.
Thank god they didn't unleash a macro system on everyone.
Macro system != C preprocessor.
Now, we'll likely not get the Lisp macro system in all its glory, but I think the point to take away (despite the short parent comment) is that its almost better not to have a broken macro system than something that is rushed an not properly implemented.
Re: Swift – observations from Rust’s original designer
#49He doesn't seem to know much about iOS or Objective-C due to that comment about parameter names probably being unused. You wouldn't be able to make meaningful method selectors calling into the code from Objective-C without them, since the names of the parameters are part of the method name in Objective-C.
func methodName(paramName: String)
and func methodName(paramName: String, otherParam: Int)
are different.I'm still playing with this but there are some interesting/weird things in here. What follows is a bunch of random observations of how named params work in Swift / ObjC. For instance:
func methodName(name name: String)
Can be shortened using a pound symbol, because the variable name within the method, and the parameter name are the same thing: func methodName(#name: String)
It also seems that most of the Cocoa APIs follow a convention, when called from Swift, of having an unnamed first parameter, and a named second parameter. e.g. this: -(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
becomes: func tableView(tableView: UITableView!, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell!
which means it's called like so: myObject.tableView(tableView, cellForRowAtIndexPath: indexPath)
If you name a parameter, you have to use the name. The order of parameters matters, and there doesn't seem to be a way to define optional method parameters (make sense as parameter names are essentially ObjC "selectors").Re: Swift – observations from Rust’s original designer
#50What are the distinctive features of Rust that Swift has that aren't in some way derived from ObjC? (I'm sure there are some; I just don't know Rust.)
Nothing unique to rust. The biggest thing I see is that it's an imperative language with functional-style ADT's, tuples, sum types, etc. It also looks fairly similar syntactically (all those let's). Not sure if there are other things it has in common.