
Swift – observations from Rust’s original designer - porada
http://graydon2.dreamwidth.org/5785.html
======
kibwen
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!

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

~~~
chc
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.

~~~
jmgrosen
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.

~~~
chc
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.

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

~~~
chc
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.

~~~
mitchty
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.

------
oscargrouch
"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/](http://nondot.org/sabre/)

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

~~~
xixixao
Funny how this just falls out of JS (in CS):

    
    
      if concrete = optional
        call concrete

~~~
stormbrew
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.

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

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

~~~
stormbrew
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.

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

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

[https://twitter.com/jopamer](https://twitter.com/jopamer)

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

~~~
iends
He is also a former typescript developer.

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

~~~
yoklov
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.

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

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

~~~
mercutio2
> 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...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Functions.html#//apple_ref/doc/uid/TP40014097-CH10-XID_213)

~~~
kennywinker
Oh cool, I definitely missed that!

------
adamnemecek
Lack of expressions and a macro system are really unfortunate.

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

~~~
adamnemecek
Macro system != C preprocessor.

~~~
ThatGeoGuy
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.

~~~
JayArby
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.

------
Tloewald
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#.

~~~
teh_klev
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?

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

~~~
twic
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.

~~~
CmonDev
// 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(); } }

~~~
twic
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.

------
pajju
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...](https://itunes.apple.com/us/book/the-swift-programming-
language/id881256329?mt=11)

Hope it helps.

------
knocte
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?

~~~
krig
\- 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.

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

~~~
scriptproof
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.

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

------
beyondcompute
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? :)

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

~~~
beyondcompute
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)?

