Live data from Hacker News

Swift – observations from Rust’s original designer

graydon2.dreamwidth.org

31–40 of 88 posts

Re: Swift – observations from Rust’s original designer

#31
post #2

Aren't the interfaces-as-generics constraints also from c#? It seems to be c# more than anything else.

Type parameters constrained by sets of method signatures dates to 1977: http://en.m.wikipedia.org/wiki/CLU_(programming_language). See also, Theta and some of Todd Millstien's work in the 1990s.

Re: Swift – observations from Rust’s original designer

#32
post #23
post #21

Earlier quoted context omitted.

They did announce they would not guarantee source compatibility until after the release date. So the language will likely change a bit still.

Huh, I must have missed that. That's definitely contrary to the message most of their stuff is putting out, which is "Go ahead and and use it to write applications." Thanks for pointing that out.

There is a context you're missing. Use it sure, but be ready for them to change things prior to GA.

This happens pretty often in their betas. First few iterations of even new frameworks can end up doing vastly different things than later versions.

Re: Swift – observations from Rust’s original designer

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

Protocols being used both as type parameter constraints and as types themselves reminded a few people of Rust's traits, but of course Rust didn't come up with those from whole cloth either.

Re: Swift – observations from Rust’s original designer

#35
post #17

Earlier quoted context omitted.

I'm not sure what makes you think they won't release it; they typically release their LLVM work and the stuff they build on top of it at some point.

I don't mean that they won't release it, but that they haven't indicated any intention to release it except as a binary thrown over the wall into their developer program. They just held a very big developer conference and made no mention of it being free or open-source. Their "LLVM work" up till this point has all been C and Objective-C stuff that's part of the LLVM Project and they have made a big point of that, so…

The C stuff wasn't part of LLVM until Apple made clang, a separate C frontend which uses LLVM. It's part of the LLVM project only because they contributed it; there's no particular inherent reason it had to be.

Re: Swift – observations from Rust’s original designer

#37
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 ;)

To be fair, you can also do `optional.map(|concrete| { ... })`. I'll admit that's not quite as nice as Swift's, though.

Re: Swift – observations from Rust’s original designer

#38
post #29
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 ;)

Funny how this just falls out of JS (in CS): if concrete = optional call concrete

Pretty much every language to date allows this construct. And it's often considered a bad idea in languages where = is assignment because it's so easy to get it confused with == and accidentally assign to the thing you're trying to compare to, which will usually evaluate to truthy.

The special things about the way it works in Swift are:

- You have to put let in front, thus avoiding the confusion.

- If the RHS is optional it unwraps the option for the success branch, but the variable is not available in any other scope, thus ensuring safe use.

In JS, C, CS, Ruby, etc. you're not really doing anything useful if you assign a value to another name just for one branch of an if statement. In Swift you are.

Re: Swift – observations from Rust’s original designer

#39
post #26

Does he knows something of Obj-C? Because a lot what he says coming from elsewhere was already well known in Obj-C, like named parameters, "protocols", etc. Which he barely mentions. I think in the light of Obj-C, the newer C# would be less mentioned.

Objective-C doesn't really have named parameters. Objective-C has arguments spliced into the selector at each colon. (Of course, Swift inherits the selector->parameter limitation, but it goes to somewhat greater lengths to hide it.)

I'm pretty sure that Objective-C's named parameters actually have priority over all other forms, being from the nearly identical form they took in Smalltalk. It's only recently that languages have had the looser form of named parameters where their order doesn't matter and they're mostly just a way to disambiguate default arguments.

The Smalltalk form is actually more powerful, since it gives you a kind of multiple dispatch (a.la. C++ argument overloading) that would be quite expensive in a non-statically typed language otherwise.

Re: Swift – observations from Rust’s original designer

#40
post #6

Earlier quoted context omitted.

How much cleaning up do you expect at this point? It's already both announced and released to developers. Obviously it's not 100% finished, but if they intended to open-source it, I wouldn't expect that announcement to come after publicly releasing it.

They haven't publicly released it yet. Xcode 6 which includes Swift is currently part of the beta available as part of the Apple Developer Program. That means it is still under NDA as well. Most likely after Xcode 6 is released publicly (i.e. available on the Mac App Store) they will do a code dump back to the LLVM project.

> That means it is still under NDA as well.

Partially. They made the language manual freely available on the iBookstore.

Post reply on HN