He may have heard it direct from Apple. They have a close partnership for developing enterprise iOS apps, and have been for almost two years.
I had no idea myself until I went to interview at IBM. I haven't had the opportunity to work with Swift professionally though, so they went with someone else. Possibly the OP :P
it is not there. https://github.com/apple is accessible .
i guess OP somehow found this website and put it into HN. I don't even see any press release by Apple related to this thing yet.
This is good news (hoping the github link etc will start working in a day or two)! One side effect of swift being open sourced is that more developers will start looking at it for server side development. However, I personally think that Swift will continue to have strong reliance on Apple (esp considering that most external Swift developers will come from iOS development). So, till I see Apple showing interest in Swift getting used on server side, I'll not use it there.
esp considering that most external Swift developers will come from iOS development
I am wondering about this. To me, it seems that there is still space for a modern, pragmatic language that compiles to native code. Coming from C and C++, I have been using Go recently for applications where garbage collection and some performance loss due to a relatively weak compiler is acceptable.
However, I still find the lack of parametric polymorphism tedious and annoying as well as other stuff you'd come to expect from a modern language (algebraic data types, non-nullable types, etc.).
Does anyone who has experience with Swift think that it could be a better language for the niches Go has gained traction? (Besides iOS/Mac development?)
I experimented with D ~2008-ish. IMO it's definitely superior to Go. The problem is that D is probably not going to gain critical mass anymore (I expect the same for Nim). This has an impact on its future ecosystem.
Since Swift is pushed by Apple, it probably won't suffer from the same ecosystem problems.
> (I expect the same for Nim). This has an impact on its future ecosystem.
What do you expect from a future ecosystem?
Nim has seamless integration with C as it compiles to C anyway, so there should be no concerns about that.
It's amazing that really powerful languages are never mainstream. Lisp, Ada, Ocaml, D and Nim will go their way in the future, they are just not as much in the focus of public attention as modern trends like Rust and Swift which are advertised by big organizations like Mozilla and Apple.
I have worked extensively with both Swift and Go. The currently available Swift implementation in Xcode is fairly closely tied to Cocoa (and hence OS X); I think this would be a serious barrier to generic server-side usage of Swift, so I'm curious to see if they have done anything about that (and what).
Otherwise, it's a fairly decent language. It doesn't have Go's concurrency baked in to the language, but on OS X you can use Grand Central Dispatch (libdispatch) which is a very decent concurrency library and it works very well with Swift, I'm hoping it will be available in the Linux port of Swift as well.
Besides the more sophisticated type system, a major advantage (or disadvantage, depending on how you look at it) of Swift over Go is it's memory management mechanism: it uses Automatic Reference Counting, which makes garbage collection more deterministic and efficient, at the expense of a certain level of overhead in the developer's thought process (e.g. the developer has to be mindful of things such as reference cycles etc).
It's not ready for production in this release according to the site but libdispatch and Foundation are both being ported which should speed up server side development on Linux.
Node.js made server side Javascript a reality, but it was done by outsiders using Google's V8 engine rather than by Google itself. What would be wrong with server side Swift being similarly pushed by a 3rd party?
EDIT: I'm joking of course. More likely, they realized they accidentally forgot to excise some incredibly sensitive private information from the repo's history and are working fast on it before they make the repo public again.
If you just want to play with the REPL (usr/bin/swift in the Ubuntu 14.04 snapshot), all you have to do is:
apt-get install python-dev
If you want to actually compile swift files (usr/bin/swiftc in the Ubuntu 14.04 snapshot), it appears extremely basic programs will compile with jessie's clang-3.5, so all you have to do is:
apt-get install clang
Note that the swift.org instructions claim you need clang-3.6, and you probably do for more complex programs. For that, you'll need to temporarily add a sid/unstable source and upgrade clang:
And slightly more specific, Swift on Android :) LLVM compiles some code I'm working on to be part of an Android app; so it should not be too hard (as LLVM is Swift compiler backend).
I find package management unscaleable (ie, it becomes more and more of headache as you pull in dependencies), but the language is much, much nicer to work with and read than Objective-C
Swift is a very nice language.
And it's pretty easy to learn too - it took me about 2 weeks to get the basics of it and in 1 month I was producing code at the same speed as with Objective-C.
After a couple of months of Swift-ing, I now started a project in C++ and while it's nice to be back home (in the C++ world), I immediately feel like I'm on my own - C++ doesn't make any attempt to protect me from myself (although it feels like I have more power to do what I want).
The Swift compiler, on the other hand, will obsessively stop me from fitting a square into a circle and will only allow me to do that if I declare loud and clear that "I know what I'm doing!".
I've been developing on iOS since it came out. It is better than ever. Swift is a great language in my opinion – feels very familiar to Objective-C, but is much lighter-weight, and I find that I can spin up projects much more quickly. The type-safety took some getting used to, but pays dividends and has made programs easier to expand and maintain. Plus, I get to pull in ideas from the functional programming community which is great.
It looks like he managed to go through a whiteboard coding exercise in the end! As far as I know, Apple follows roughly the same hiring practices as Google. Well done (no sarcasm here, it's probably great to work at Apple)!
Google doesn't provide feedback on why they reject you. For example, you could be the world's foremost expert on Erlang. But the department interviewing you needs a C++ programmer.
You'd never know that was the reason. You'd just be notified that you weren't called back for another interview and asked to please check back for more positions in a few months.
Actually, you can extract some info from the recruiters. Just ask them, tell them you need it to prepare better next time, tell them you know the reason but want to cross check etc. They will tell you
I was just rejected by Google. They will give feedback -- in my case, the recruiter said that they were worried I didn't seem to care whether my code would actually work as written.
Yea that's great; he's has a clear understanding of what it means to write and maintain a third party package[1] and he's also exceptionally good at writing documentation and code samples[2].
Apache 2.0 License + Runtime Library Exception + copyright owned by the contributor (i.e. no assignment or CLA) + good community structure and documentation + code of conduct... well done, Apple!
Anybody knows what effects of the "copyright owned by the contributor" are in the context of Swift's Apache license?
I guess the "good side" is that the lawyers of other companies probably like when the code made by their programmers keeps being copyrighted by the company. But it is still an Apache license, so they can't demand too much from the users of the code.
Still, are there any negative aspects? Any imaginable danger?
Can the standard library have problems with (once in the future) having different copyright holders for its different parts?
"copyright owned by the contributor" means that as the project matures there will be way too many contributors. To change the license for the project to something that is not Apache-compatible Apple would have to ask every contributor to re-license their code, and if the code author disagrees re-implement corresponding parts. In practice that's a signal to every one that the licensing terms are very unlikely to ever change.
Your typical corporate IP lawyer might feel queasy about the collective copyright aspect, but so much of the open source world works this way now... they can suffer in their jocks.
One important question they'll ask is: "Who can enforce the copyright and licence?" (Which is when the subtle difference between joint and collective copyright matters.)
Non-trivial contributions are made under the terms of the Apache 2.0 Licence, so regardless of who owns the copyright, everyone operates under those same terms.
One common rationalisation for copyright assignment is ease of relicensing, should it be necessary. That's much less important when operating under the terms of a permissive license.
> Your typical corporate IP lawyer might feel queasy about the collective copyright aspect, but so much of the open source world works this way now... they can suffer in their jocks.
This is a bad attitude if you want buy-in from large organizations. If you're not worried about that, no problem, but if buy-in is your goal (and I'm sure it's Apple's goal here) you can't just tell potential contributors to "suffer in their jocks."
Sure, it's flippant, but do recall that the entire concept of open source absolutely terrified IP lawyers not that long ago (and in some cases, still does).
Lawyers who are too conservative to allow their company's developers to contribute to open source projects (that they don't own) have a problem. Open source is way beyond pussy-footing around just to make corporate lawyers feel comfortable.
And seriously, if Apple can do it, why can't they?
This comment doesn't make a lot of sense. The "corporate IP lawyers" being referred to would be Apple's own counsel, not those of "potential contributors".
The answer is only the owner of an exclusive right of copyright has standing to sue. So any of these open source projects that have no copyright assignments would have trouble suing. But in practice, who cares. Unless you want to sue people, it literally doesn't matter.
The only folks who often care about suing are those who are trying to enforce certain types of share-alike licenses (GPL, etc) because they are ideological.
If you are using Apache or BSD, you probably aren't suing folks because you are fine with them commercializing it or doing whatever with it (and if you are using these liceneses and aren't okay with that, you may want to reevaluate your life choices)
Joint holders can also enforce copyright, though open source codebases work more like collective copyright. That said, non-exclusive Linux kernel copyright holders have performed enforcement activities (quietly or noisily)...
"Joint holders can also enforce copyright, though open source codebases work more like collective copyright."
Joint copyright is basically non-existent in the US. For example, you must intend to create a joint work at the time of creation. You can't make it joint later on by signing a document saying it's joint with someone. There are other issues too.
This is deliberate, as joint owners each own a 100% enforceable set of rights, and the law doesn't really want tons of people running around claiming to own the same work.
"That said, non-exclusive Linux kernel copyright holders have performed enforcement activities (quietly or noisily)..."
Not in the US. It's not possible in the US. It'll get dismissed immediately.
Aside from the hilarious description of Oracle [t=2107], it's worth watching "The Rise and Development of illumos" [1] as it discusses some consequences of signing away copyright on your contributions to an open source project.
I find his speaking style extremely irritating. I can't take more than a few minutes of this. I'm sure it's full of substance, though. Perhaps there's a transcript somewhere?
I hope Bryan once publishes the annotated presentation? I'm also one of those who have problems following the narration in the video. Until then, I've posted a link to the slides here (see my other post).
Sun Microsystems released the Solaris operating system source code, but required all contributors to handle the copyright ownership on their code to Sun.
Then, shortly after Sun acquisition, Oracle closed the Solaris code and got away with all contributors' copyrights.
What it means from a legal standpoint is that Apple is bound by the same terms as everybody else.
The way it works is this: Apple is making Swift available to you (and others) under Apache 2.0. You send in some changes, which you make available to Apple (and others) under Apache 2.0. Everyone is on equal footing, and Apple can't relicense it to someone else on terms of their choosing that involve, for example, neutering the patent grant's self-destruct clause.
This was the default way that open source worked for years, before people started cargo-culting the (totally unnecessary) CLA process into their projects.
What it means from a practical standpoint, though, is that the project is easier to contribute to, what with the impedance imposed by a CLA process being, you know, non-existent.
That ridiculous: "started cargo-culting the(totally unnecessary) CLA process"
It's so they can re-license in the future. There are some projects with so many authors that it is impossible to re-license because you need sign-off by every single person, even if it makes sense to re-license.
From a contributer's point of view, the inability to re-license practically is often a feature, not a bug. CLAs make the worst case scenario touted by GPL advocates about non-GPL licenses practical: They can profit directly and exclusively from your work without your direct consent.
Also the ability to relicense an Apache License 2.0 work is relatively unimportant (compared to, say, the ability to relicense something under a more restrictive license like the GPL).
GNUstep developers stated several times that they'll implement bindings for Swift if it's released as open source. Though from my personal (and very limited) experience I may suggest that you won't use it for cross platform development. It's works on Linux reasonable well, but support for Windows is limited or at least it's was few years ago.
Hope it's will have brighter future outside Apple ecosystem. It's nice to have more tools for server-side development, but wish it's will be better on desktop than ObjC / Cocoa / GNUstep was.
They're releasing the source code to libdispatch? I thought that was one of Apple's trade secrets, and more applicable than just Swift apps since it's a C lib?
A lot of folks to thank at Apple right now, can't wait until all of this propagates so we can take a look at what's new in Swift 3. Two thoughts:
- VERY happy to see the open sourcing of much of the Foundation libraries (which includes strings, dates, networking primitives, concurrency/task queues, I/O, etc). It'll provide a very strong start and make working with Swift immediately productive.
- Holy crap, there's a package manager. This has been sorely needed since about day one of Swift development, glad to see that it's been a priority as part of the effort to open source!
Historically they haven't been, and the page about planning for Swift 3.0 says it will introduce breaking changes. (It also mentions that Swift 2.2 will be released in the interim and its compiler will try to warn about things that will be broken in 3.0 so you can get your code ready early.)
It's interesting to compare Swift 2 -> 3 to the Python 2 -> 3 upgrade experience. Apple will simply break whatever they need to break to get the improvements they decide would be valuable, move on, and anyone who doesn't follow is likely to be left in the dust.
Frankly, I welcome it after years of feeling like the only Python 3 user on Earth.
For the next few years, I expect Apple will wield a great deal more power over the Swift user community than the Benevolent Dictator For Life has wielded over his supposed minions. I hope we'll get a better language this way, and that these changes won't simply break third-party products to make changes that mostly benefit Apple.
Rich, powerful giant gives power to fork to the little people. Will it be like C#? Like Java? Eventually like Python? Should be interesting....
Swift 3 will be ABI stable, so things will break less - that might not include standard library stability, but Swift projects currently include a copy of the standard library to avoid that.
It's kinda maddening sometimes, I have an app that every time XCode is updated it pretty much has at least one little change that has to be done to get it to build again. It makes me somewhat dread every update.
But, at the same time, they keep users upgrading at the same relentless pace and so you generally don't need to worry about supporting 10 year old versions of the OS.
Swift does not have a large userbase for now, and users adopting it are anticipating the breaking changes from beginning. When it stabilizes and developers grow, breaking changes will be less likely.
These circumstances are no where near the same: Swift is a compiled language, and they carefully made the decision to embed all of Swift and its runtime libraries in your application, allowing them to break things without disrupting existing applications and without needing backwards compatibility cruft in their operating system. They also have essentially been actively discouraging people from writing libraries in Swift by pointing out constantly that there is not a stable ABI, so you only see a small handful of things written for it in comparison to Python.
It doesn't look like they've opened any of the existing Foundation framework we all know and love and that's written in Objective-C. The swift-corelib-foundation repo contains a bunch of .swift files, and those contain lots of calls to NSUnimplemented().
The Foundation stuff is a complete Swift re-implementation of Foundation (fairly impressive goal) and is still in-progress (basic classes like NSArray and NSData look complete but none of NSURLConnection is implemented). They are targeting Swift 3 to have them complete. As the Core Libraries project page says:
"These libraries are part of the work towards the future Swift 3 release. They are not yet ready for production use, and in fact are still in the earliest stages of development"
457 comments
[ 3.6 ms ] story [ 290 ms ] threadThis organization has no public repositories.
Edit: Though I suppose the tools are only provided as binaries.
https://github.com/apple/swift
EDIT: Works at IBM. SORRY.
I had no idea myself until I went to interview at IBM. I haven't had the opportunity to work with Swift professionally though, so they went with someone else. Possibly the OP :P
https://www.apple.com/pr/library/2014/07/15Apple-and-IBM-For...
(1) psuter.net
I am wondering about this. To me, it seems that there is still space for a modern, pragmatic language that compiles to native code. Coming from C and C++, I have been using Go recently for applications where garbage collection and some performance loss due to a relatively weak compiler is acceptable.
However, I still find the lack of parametric polymorphism tedious and annoying as well as other stuff you'd come to expect from a modern language (algebraic data types, non-nullable types, etc.).
Does anyone who has experience with Swift think that it could be a better language for the niches Go has gained traction? (Besides iOS/Mac development?)
Since Swift is pushed by Apple, it probably won't suffer from the same ecosystem problems.
What do you expect from a future ecosystem?
Nim has seamless integration with C as it compiles to C anyway, so there should be no concerns about that.
It's amazing that really powerful languages are never mainstream. Lisp, Ada, Ocaml, D and Nim will go their way in the future, they are just not as much in the focus of public attention as modern trends like Rust and Swift which are advertised by big organizations like Mozilla and Apple.
Otherwise, it's a fairly decent language. It doesn't have Go's concurrency baked in to the language, but on OS X you can use Grand Central Dispatch (libdispatch) which is a very decent concurrency library and it works very well with Swift, I'm hoping it will be available in the Linux port of Swift as well.
Besides the more sophisticated type system, a major advantage (or disadvantage, depending on how you look at it) of Swift over Go is it's memory management mechanism: it uses Automatic Reference Counting, which makes garbage collection more deterministic and efficient, at the expense of a certain level of overhead in the developer's thought process (e.g. the developer has to be mindful of things such as reference cycles etc).
D won't be fully a player in that space until the GC is fully optional - meaning no library code causes the GC to run unexpectedly.
I'm excited about Swift for desktop/simulation/gaming/embedded development. I'm sure there'll be a Windows port in the near term as well.
https://swift.org/source-code/ https://github.com/apple/swift
EDIT: I'm joking of course. More likely, they realized they accidentally forgot to excise some incredibly sensitive private information from the repo's history and are working fast on it before they make the repo public again.
If you just want to play with the REPL (usr/bin/swift in the Ubuntu 14.04 snapshot), all you have to do is:
If you want to actually compile swift files (usr/bin/swiftc in the Ubuntu 14.04 snapshot), it appears extremely basic programs will compile with jessie's clang-3.5, so all you have to do is: Note that the swift.org instructions claim you need clang-3.6, and you probably do for more complex programs. For that, you'll need to temporarily add a sid/unstable source and upgrade clang: (don't forget to remove the unstable line afterwards).After a couple of months of Swift-ing, I now started a project in C++ and while it's nice to be back home (in the C++ world), I immediately feel like I'm on my own - C++ doesn't make any attempt to protect me from myself (although it feels like I have more power to do what I want).
The Swift compiler, on the other hand, will obsessively stop me from fitting a square into a circle and will only allow me to do that if I declare loud and clear that "I know what I'm doing!".
You might really like Haskell :)
[1] https://swift.org/package-manager
Both Cocoapods and Carthage should eventually be phased out with an official package manager.
https://github.com/apple/swift-package-manager/graphs/contri...
You'd never know that was the reason. You'd just be notified that you weren't called back for another interview and asked to please check back for more positions in a few months.
They recruited me through the code jam, but hey.
1: https://github.com/Alamofire/Alamofire
2: http://nshipster.com
I guess the "good side" is that the lawyers of other companies probably like when the code made by their programmers keeps being copyrighted by the company. But it is still an Apache license, so they can't demand too much from the users of the code.
Still, are there any negative aspects? Any imaginable danger?
Can the standard library have problems with (once in the future) having different copyright holders for its different parts?
Your typical corporate IP lawyer might feel queasy about the collective copyright aspect, but so much of the open source world works this way now... they can suffer in their jocks.
One important question they'll ask is: "Who can enforce the copyright and licence?" (Which is when the subtle difference between joint and collective copyright matters.)
Non-trivial contributions are made under the terms of the Apache 2.0 Licence, so regardless of who owns the copyright, everyone operates under those same terms.
One common rationalisation for copyright assignment is ease of relicensing, should it be necessary. That's much less important when operating under the terms of a permissive license.
This is a bad attitude if you want buy-in from large organizations. If you're not worried about that, no problem, but if buy-in is your goal (and I'm sure it's Apple's goal here) you can't just tell potential contributors to "suffer in their jocks."
Lawyers who are too conservative to allow their company's developers to contribute to open source projects (that they don't own) have a problem. Open source is way beyond pussy-footing around just to make corporate lawyers feel comfortable.
And seriously, if Apple can do it, why can't they?
The answer is only the owner of an exclusive right of copyright has standing to sue. So any of these open source projects that have no copyright assignments would have trouble suing. But in practice, who cares. Unless you want to sue people, it literally doesn't matter.
The only folks who often care about suing are those who are trying to enforce certain types of share-alike licenses (GPL, etc) because they are ideological.
If you are using Apache or BSD, you probably aren't suing folks because you are fine with them commercializing it or doing whatever with it (and if you are using these liceneses and aren't okay with that, you may want to reevaluate your life choices)
Joint copyright is basically non-existent in the US. For example, you must intend to create a joint work at the time of creation. You can't make it joint later on by signing a document saying it's joint with someone. There are other issues too.
This is deliberate, as joint owners each own a 100% enforceable set of rights, and the law doesn't really want tons of people running around claiming to own the same work.
"That said, non-exclusive Linux kernel copyright holders have performed enforcement activities (quietly or noisily)..."
Not in the US. It's not possible in the US. It'll get dismissed immediately.
[1] https://www.youtube.com/watch?v=-zRN7XLCRhc
Then, shortly after Sun acquisition, Oracle closed the Solaris code and got away with all contributors' copyrights.
http://www.slideshare.net/bcantrill/fork-yeah-the-rise-and-d...
The direct link to the Oracle part:
https://www.youtube.com/watch?v=-zRN7XLCRhc&t=2107
The way it works is this: Apple is making Swift available to you (and others) under Apache 2.0. You send in some changes, which you make available to Apple (and others) under Apache 2.0. Everyone is on equal footing, and Apple can't relicense it to someone else on terms of their choosing that involve, for example, neutering the patent grant's self-destruct clause.
This was the default way that open source worked for years, before people started cargo-culting the (totally unnecessary) CLA process into their projects.
What it means from a practical standpoint, though, is that the project is easier to contribute to, what with the impedance imposed by a CLA process being, you know, non-existent.
It's so they can re-license in the future. There are some projects with so many authors that it is impossible to re-license because you need sign-off by every single person, even if it makes sense to re-license.
Can you explain what's ridiculous about the part of my comment that you quoted?
https://github.com/apple/swift-package-manager/blob/master/D...
https://libdispatch.macosforge.org/post/libdispatch-is-open-...
- VERY happy to see the open sourcing of much of the Foundation libraries (which includes strings, dates, networking primitives, concurrency/task queues, I/O, etc). It'll provide a very strong start and make working with Swift immediately productive.
- Holy crap, there's a package manager. This has been sorely needed since about day one of Swift development, glad to see that it's been a priority as part of the effort to open source!
Are new versions backwards compatible?
Frankly, I welcome it after years of feeling like the only Python 3 user on Earth.
For the next few years, I expect Apple will wield a great deal more power over the Swift user community than the Benevolent Dictator For Life has wielded over his supposed minions. I hope we'll get a better language this way, and that these changes won't simply break third-party products to make changes that mostly benefit Apple.
Rich, powerful giant gives power to fork to the little people. Will it be like C#? Like Java? Eventually like Python? Should be interesting....
But, at the same time, they keep users upgrading at the same relentless pace and so you generally don't need to worry about supporting 10 year old versions of the OS.
Cuts both ways I guess!
The Core Foundation stuff (included in swift-corelib-foundation) has been open for a while: http://www.opensource.apple.com/source/CF/
"These libraries are part of the work towards the future Swift 3 release. They are not yet ready for production use, and in fact are still in the earliest stages of development"
While not first-party, https://github.com/Carthage/Carthage
Swift's appears to possibly be limited to Swift, so Carthage will still be useful to integrate with Objective-C frameworks.