Live data from Hacker News

Swift – observations from Rust’s original designer

graydon2.dreamwidth.org

41–50 of 88 posts

Re: Swift – observations from Rust’s original designer

#41
post #24

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.

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).

Re: Swift – observations from Rust’s original designer

#42
I 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.

Re: Swift – observations from Rust’s original designer

#43
To those wondering why Graydon is qualified in the title as just the "original" designer of Rust, it's because (as far as anyone seems to know) years of being a technical lead wore him down (lots of administrative tasks and infrastructural tasks, little coding) and the fact that the position of BDFL was foisted upon him unwillingly, to his chagrin. He abdicated the project last year, though I still keep hoping that we'll entice him back someday!

Re: Swift – observations from Rust’s original designer

#44
post #41

Earlier 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).

Oh, you're totally right. Sorry, my parser is buggy!

Why couldn't he have just have written "(Swift ∖ ObjC) ∩ Rust"? :)

Re: Swift – observations from Rust’s original designer

#45
post #13

I 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 ;)

Really agree that Rust should put some sugar on this construct. The way Swift is doing it seems so natural, too.

Re: Swift – observations from Rust’s original designer

#46

I 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.

I don't believe the author is 'pimping' Rust. "C#" appears five times on the page, in snippets like this:

    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

#47
He 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.

Re: Swift – observations from Rust’s original designer

#48
post #34

Earlier quoted context omitted.

Thank god they didn't unleash a macro system on everyone.

Macro system != C preprocessor.

To be honest I would be disappointed if they let loose a macro system that is as incomplete as the C preprocessor. I'll be much happier if in a year or two they add a proper, more well thought out macro system to the language which aids in readability rather than ruins it.

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

#49
post #47

He 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.

Method parameter names are used similarly in Swift as in ObjC. For example two methods can have the same name, as long as they have a difference set of parameters. For example:

    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

#50
post #30
post #24

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.)

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.

[deleted]
Post reply on HN