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