Swift – observations from Rust’s original designer | Hacker News Reader

Swift – observations from Rust’s original designer

graydon2.dreamwidth.org

344 points_sv3a84 comments

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!

He seems to generally like it -- similar to Rust in a lot of ways, but a little higher-level, which is appropriate for its intended uses (iOS and OS X apps). He nor I seem to think that it can replace Rust (especially if they don't open it up!), but it definitely seems like a compelling option.

EDIT: Does anyone know if it's possible to try it without a paid iOS / OS X dev license? I'd especially like to try the playground, but I'm not willing to dump $100 on it.

They used to offer free student developer memberships, but I think they stopped that a while back. Now you have to be part of one of the paid programs (or be part of a university that's signed up with Apple).

It is pretty disappointing that Apple is walling in Swift like this. I was excited about it to begin with, because it looks like a great language, but apparently as Microsoft moves toward openness, Apple is doing the opposite. Now I'm not really sure what to do with it.

I wouldn't be surprised if Apple ends up open sourcing Swift after it cleans it up, perhaps even making it an LLVM project. I see it similarly to how they handled their own AArch64 backend -- proprietary at first, but mostly for secrecy before it was announced and then merging it with the preexisting backend after it was announced.

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.

I'll grant you that. The compiler/llvm/clang parts of it though are still under NDA.

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.

And promised converters for any source changes necessary. I expect it'll be similar to the Convert to ARC and Objective-C Literals Menu items in Xcode.

I agree open sourcing this would be the logical move and maybe even open up its usage outside the iOS/OS X ecosystem long term, which would be in the best interests of Apple, but it's not ready for production use yet - from their announcement page:

And when iOS 8 and OS X Yosemite are released this fall, you can submit apps that use Swift to the App Store and Mac App Store.

This is intended as a beta, and they won't even allow you to use it in production yet, even if you wanted to, so you can expect some small changes to the language spec as they refine it. Typically the xcode betas can't be used to submit, and Apple have released other projects closed source before open sourcing them (for example webkit).

It's interesting that they're moving development on both platforms to this new language. I wonder when we'll see a unified API?

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 I don't really see how it reflects on this, which is not part of the LLVM Project and is not based on existing cross-platform languages where they're competing with other open-source tools.

A proprietary Swift even sort of makes logical sense. I could easily see Apple thinking that since Swift is intimately tied to its proprietary system frameworks, Swift should be proprietary too.

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.

Xcode 6 is currently in beta, the beta is part of the dev program. Just like the new Yosemite beta is part of the dev program.

Once Xcode/Yosemite are no longer beta they will be released for free, just like the existing Xcode that is freely available from the MAS.

I don't know that there is much question of replacing Rust when it isn't in use except as an unstable experiment with a lot of interest. You could replace Rust with outright vaporware.

Why is that comment getting voted down? Everything it states is true.

Rust isn't stable. It really hasn't seen any serious use.

Even the Rust home page itself currently states, "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry."

It's still in development, but it's a far cry from vaporware, and it's already being used in production at at least one company.

pekk isn't saying Rust is vaporware. The meaning of pekk's post seems to me to be "Since Rust is almost never used in production, outright vaporware would allow people to do the same thing they mostly do with Rust: not use it." In other words, Rust has not yet found a niche, so you can't supplant it in a niche it doesn't yet exist in.

Rust is not vaporware under any reasonable definition of that word; there is plenty of Rust there to run. It is not stable yet, to be sure; but there are plenty of people happily using it, some even in production.

The person you replied to did not say that Rust is vaporware.

At worst, it says that Rust's toehold is tenuous enough that even vaporware could replace it. I don't agree with that, but I can understand the sentiment. Think "knocked back with a feather".

You only have to be a paid developer to get the beta of XCode; once it comes out of beta, it'll be available on the Mac App Store for free.

That said, it'd be nice to see Swift get open sourced at some point.

I'm afraid that it's going to be tied too tightly to the Cocoa Runtime to make opening the language up feasible without also opening Cocoa up.

I don't think so. It seems to me that they did a good job on the interface between Objective-C and Swift, so one could perfectly live without the other. Objective-C constructs are exposed as native Swift constructs.

If they open sourced the compiler then maybe you could link against GNUstep on other platforms.

You're thinking of the Objective-C runtime, which in fact is opensource: http://www.opensource.apple.com/source/objc4/objc4-551.1

C# is "open source", but the CLR is not.

That's their hope - after 1.0, they want to open-source it.

"I started work on the Swift Programming Language (wikipedia) in July of 2010. I implemented much of the basic language structure, with only a few people knowing of its existence. A few other (amazing) people started contributing in earnest late in 2011, and it became a major focus for the Apple Developer Tools group in July 2013. The Swift language is the product of tireless effort from a team of language experts, documentation gurus, compiler optimization ninjas, and an incredibly important internal dogfooding group who provided feedback to help refine and battle-test ideas. Of course, it also greatly benefited from the experiences hard-won by many other languages in the field, drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list."

- Chris Lattner, http://nondot.org/sabre/

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

I REALLY like that syntax for the maybe monad.

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.

That's a bad idea if "optional" is a number, a boolean or a string.

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

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

You could always write this yourself with a macro:

    macro_rules! if_let {
      ($p:pat = $init:expr in $e:expr) => {
        { match $init { $p => $e,_  => {}, } }
      }
    }

    fn main() {
      let tup = (2, 3);
      if_let!{(2, x) = tup in println!("x={}", x)}; // prints x=3
      if_let!{(5, x) = tup in println!("x={}", x)}; // doesn't print
    }

It's slightly more heavyweight, but still not too bad.

Bleah, Rust's println makes my eyes bleed.. What's didn't you do 'println!("x value={x}");'?? Yes, I know you can use 'println!("x value={u}",u=x);', it still isn't a good syntax IMHO.

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.

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

I agree, it seems to be heavily influenced by C#. I am primarily a C# dev and reading through the code and docs I seem to have no mental friction, as opposed to ObjC which seemed to make me bang my head on my desk.

I think any attempt to precisely pin down where a particular language feature has come from or where a language draws inspiration from is pretty futile.

Many language constructs were invented simultaneously under different names in different languages.

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.

One of the Swift developers is a former F# dev:

https://twitter.com/jopamer

The language seems more closer to F# than C# to me. It's all good though!

He is also a former typescript developer.

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

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

Why couldn't he have just have written "(Swift ∖ ObjC) ∩ 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.

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.

I think graydon is reaching here, while there may be some intersection of features in Rust and Swift, I don't really see any Rust influence at all.

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

> and there doesn't seem to be a way to define optional method parameters

Did you miss the part about default values?

If you're calling an Objective-C selector with more than one argument, you are indeed using an external parameter name, but external parameters are explicitly not required if you're writing pure Swift.

https://developer.apple.com/library/prerelease/ios/documenta...

Oh cool, I definitely missed that!

Lack of expressions and a macro system are really unfortunate.

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.

The C preprocessor is bad enough; it's much better if a separate macro language can be avoided altogether, leaving a single consistent syntax for the language. If there has to be a macro system, I would greatly prefer a simple preprocessor to a more powerful system that would allow even greater convolution of the syntax.

A lot of the features allegedly inspired by C# actually come directly from Objective-C. It's a decent discussion (I also skimmed the manual front to back after the presentation) but it's sad the writer appears ignorant of how advanced a language Objective-C is/was, especially since it significantly predated C++, let alone Java and C#.

Sure, but can you explain which features rather than leaving off at the author is "ignorant".

Are there features in Objective-C available now that weren't present back in the early days? Perhaps this is what the author means? Has Objective-C drawn inspiration from newer languages such as C# or Java?

According to Wikipedia, both C++ and Objective-C "appeared in" 1983. I otherwise share your sentiment.

"Protocols get to play double duty as either concrete types (in which case they denote a reference type you can acquire with as from any supporting type) and as type constraints on type parameters in generic code. This is a delightful convenience Rust stumbled into when designing its trait system and I'm glad to see other languages picking it up. I'm sure it has precedent elsewhere." - C# again.

PS: Apple says "Swift is an innovative new programming language"! Just like everything else they do lately!

This is what annoyed me most about the whole Swift presentation. Swift is not in any way shape or form innovative, in terms of language features or design. It is however, another language that aims to be as productive as possible, while still being safe, like Java, C#, Rust, Go etc.

It'd be far more interesting to compare it to them (especially where they have bindings for iOS e.g. Java, C#) in terms of productivity, code maintainability, readability etc, instead of in terms of language features.

Haskell has it for its type classes in the form of existentials[1] too:

  forall a. SomeClass a => a

in Haskell is quite similar to

  &SomeTrait

in Rust.

[1] http://www.haskell.org/haskellwiki/Existential_type

I pretty much only know Java and shell script. Could someone perhaps explain what this "double duty" is? A small example would be really helpful.

// protocol = interface

interface ISample { void Process(); }

ISample sample = new ConcreteSample(); // Duty #1

class GenericSampleProcessor<T> : where T : ISample // Duty #2

{ public void Process(T sample) { sample.Process(); } }

Ah, i see, thanks.

It's the same in Java:

  ISample sample = new ConcreteSample(); // Duty #1

  class GenericSampleProcessor<T extends ISample> // Duty #2

Java got generics in 1.5, released September 2004, and bounded types like this were in that release. C# got generics in 2.0, released in November 2005, and i imagine it had them too. I assume Java lifted this idea from elsewhere. I am really quite surprised that Mr Hoare thinks this is a novel discovery in Rust.

There is the official Book coming from Apple: The Swift Programming Language by Apple Inc.

Link: https://itunes.apple.com/us/book/the-swift-programming-langu...

Hope it helps.

Couple of things that are still not clear to me, even when people keep saying that it's similar to C#:

- How about Garbage Collection?

- Many mentions to "type inference", is it then a statically-typed language? Or is it hybrid?

- Garbage Collection is handled via reference counting and ARC. No automatic cycle detection, the programmer has to manually track and resolve reference cycles. Same as using ARC in Objective C.

- It is a statically typed language. Type inference is the same mechanism as is used in C++11 with the auto keyword. Basically, anywhere the compiler can "guess" the type, you don't have to be explicit about it. Unless you want the variable to have a different type from the inferred type, that is.

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!"

It is common when a new language appears to authors to see similarity with their own language. Actually, most of the features of Swift were already implemented in some older language. Extended pattern matching for example exists in Scala.

... and in many other languages way before scala.

Yeah, that's all good. But why call people who understand that programming environments should not be opaque (and not violate elementary laws of design by obscuring readings of system's state) "livecoding nerds"? Really, why? :)

Perhaps because he doesn't see 'nerd' as pejorative.

Well, me neither. :) Although it looks a little bit suspicious in the text. But what's the relation between 'not throwing crucial design principles out of the window this time' (by not creating opaque, contrived and state-hiding system because tradition seems to approve it) and 'Live Coding' (where people see process of writing code in real-time as a part of artistic performance)?

Reply on news.ycombinator.com