I wouldn't necessarily say "never." The author says Apple has no interest in open source projects, but there is precedent with WebKit and the LLVM project. So while no one should hold their breath waiting for Apple to open source Swift's standard library and LLVM components, I wouldn't be surprised to see it happen (and wait for the inevitable Rails-like framework to sprout up. "Bullet Train" anyone?).
Clang, CoreFoundation (or rather, the CFLite subset of it), the xnu kernel, libdispatch/GCD, their Objective-C runtime, launchd, libauto (Objective-C garbage collector), mDNS/Rendezvous/Bonjour/Zeroconf, stand out as examples.
Apple is definitely not afraid of closed source when it suits them (no source code available for most system APIs or bundled apps) but they also have a fairly extensive open source portfolio.
I think you guys are in a great position now to implement a server/client solution in Swift. Effectively re-create Parse in Swift but I imagine CloudKit may have these aspirations? Any comments on what sort of competition the CloudKit brings to the BaaS table?
WebObjects hasn't been related to Objective-C for a while (It was rewritten in Java in 2001).
While WebObjects is still apparently being used by Apple's Online store and presumably some other internal applications, I wouldn't expect any serious WebObjects integration for Swift from Apple.
Wow, the OP loves jumping to conclusions. I've seen on HN a couple of threads where people claim that Apple employees say they, at a minimum, need to clean up the codebase first before open sourcing the language. While I don't know if that's true, I'm prepared to wait until Apple, not this guy, says that Swift will or will not be open sourced. Just because it's not open source now doesn't mean it'll never be.
Then they point out that there are 3rd party HTTP libraries, and completely ignore the possibility that maybe Swift might be just the thing to catalyze the creation of a new one.
To be sure, unless you're serving from an OS X based server, it'll be hard to deploy Swift-based apps until significant supporting infrastructure has been built. But I don't see any real evidence that "never" is the answer to "When Can I Code Swift on the Server?"
Sounds like an interesting case that somebody should just start a project to add swift as a frontend to GCC - maybe a kick starter project for a grad student. GCC has support for all of the language constructs that are present in swift.
If only we had Yet Another Dynamic Scripting Language (YADSL) that we could use to write web frameworks! Because there are only like 17 with full ecosystems and tools and libraries to talk to every existing database engine, yadayadayada.
What we really need is another one so that we can spend our time poking at a new language instead of building useful things! Swift would be an especially good one, since it doesn't have anything new to offer (unlike Clojure or Scala or Rust or Go) and it has great interoperability with Objective C (which Apple abandoned for server side programming in like 2005) AND it doesn't run on anything other than OSX, which is awesome because Apple discontinued Xserve over 10 years ago (EDIT: Xserve discontinued a few years ago), and there are basically no hosting providers of any kind. We could spend literally tens of person years building up all that stuff instead of using the massive infrastructure already in place!
You don't use a drill because of how interesting it is that the shape of the drill bit combined with its rotation lift material out of the hole. You do it because it works, and is efficient. A programming language is a tool, not a toy.
That's literally my entire point, stated in the form of disagreement. Why would you use a new tool that has no support and no clear advantage or distinguishing features, when there are a dozen with fully fleshed out ecosystems?
I don't think there is any other mainstreamish language with enforced option types. Even Scala and F# just cave and allow nulls everywhere. Swift's constellation of features is very interesting IMO.
1. Swift is not a mainstream language. Maybe you trust in Apple's ability to turn it into one.
2. Haskell and Common Lisp, but maybe those aren't "mainstreamish".
It's the primary language for a huge platform. I don't know how much more mainstream you can get. This seems a bit like saying, "I'm not sure the newly elected US president is a significant figure in US politics."
And no, neither Haskell nor Common Lisp are anywhere in the same city as the mainstream. For an idea of what I mean, pick a reasonably significant "target domain" for the language and consider how many major applications are written in that language. There is no platform on which Haskell or Common Lisp get used very much compared to other languages. Objective-C is clearly a dominant presence on iOS, C# rules Windows, Java has a lock on the enterprise, C and C++ are the bosses of systems programming, Haskell is…an interesting language whose motto is "avoid success at all costs."
And also, I don't think Common Lisp has enforced option types. (car '(1)) is 1 while (cadr '(1)) is NIL. Am I mistaken?
while Swift announcement may have caused a lot of hype, im pretty sure its not mainstream by now.. So Rust just fits into your concept of "mainstream", thats why i've cited it :)
> [Swift is] the primary language for a huge platform. I don't know how much more mainstream you can get. This seems a bit like saying, "I'm not sure the newly elected US president is a significant figure in US politics."
> For an idea of what I mean, pick a reasonably significant "target domain" for the language and consider how many major applications are written in that language. There is no platform on which Haskell or Common Lisp get used very much compared to other languages. Objective-C is clearly a dominant presence on iOS, C# rules Windows, Java has a lock on the enterprise, C and C++ are the bosses of systems programming, Haskell is…an interesting language whose motto is "avoid success at all costs."
Rust does not fit into this concept of "mainstream." It is a forgone conclusion that many iOS 8 apps will be written in Swift. Rust has no niche yet.
But it handles memory more like Rust than Go or something. And it's not weird like Clojure and Scala. And it doesn't have their performance quirks. And you can use the same language for iOS front ends as you do for back ends! Just like NodeJS for web apps!
Don't worry about tens of person years, there are more than enough developers who could use the attention.
First off, Swift isn't actually dynamic. It's strongly-typed (the type system itself is stronger than Java/C++) with the ability to use Protocols to do more generic things when needed.
Additionally, since the compiler is built with LLVM if Apple were to open up the language there is a strong probability that it could run on any platform LLVM supports. The main piece holding it back would be that it seems to be pretty strongly tied to CoreFoundation. Apple has a .ddl for CoreFoundation on windows though so that may not hold Swift back from being cross-platform.
On the topic of Swift's openness, it appears to be somewhat ambiguous at this time; that is, the door is neither entirely open or closed. For example, in response to general questions on this topic, Chris Lattner responded:
"We don't have anything to say about that at this point [...]"
I'd give about 95% odds that Swift will be open sourced relatively soon. That's just how Apple works at this level. They kept WebKit open source. They adopted LLVM and kept their contributions open when they could have easily made a closed fork. They built and open sourced clang even though there was nothing requiring them to.
But another aspect of how Apple works is that they love secrecy and hate making promises. They built an ARM64 backend for LLVM in private, and the first time anyone found out it existed was when they announced the iPhone 5S with an ARM64 CPU. They still ended up releasing the source code.
Right now, even the Swift compiler binary isn't publicly available. You have to have a paid developer membership to obtain it. They wouldn't open the source at this stage regardless. They most likely will, but they also most likely won't commit to anything until the initial public release.
It looks like that applies to WebCore and JavaScriptCore but not WebKit, since that's built on top of the LGPL parts as a separate entity. From Wikipedia, "WebKit's JavaScriptCore and WebCore components are available under the GNU Lesser General Public License, while the rest of WebKit is available under a BSD-style license."
So, I would say "not enough evidence" to make a call on Swift. Clang's the only from-scratch project that was open-sourced, right? Same author though, so I think the chances are fairly good, but how long is the bigger question.
I should say that you're right about "not enough evidence". I think it's safe to say that it's likely, but with Apple, nothing is certain until they announce it and sometimes not even then.
You'll find a bunch of open-source projects that Apple has contributed code to (LLVM, WebKit, CUPS), as well as a bunch that they wrote and released (launchd, clang). They've recently released their ARM64 backend for LLVM.
I will be surprised—extremely so—if Apple choose not to open-source Swift. It has no downsides for them, and it's obvious that many people will simply refuse to get involved with it if they don't.
Apple hasn't so much contributed to LLVM and Webkit as fundamentally enabled them, right? Chris Lattner is an engineering lead at Apple, for instance.
I agree with your prediction about Swift being open sourced. Among other things: as nice as Swift might be, its #1 value proposition is "easy to build iOS applications in", so the more people using it the bigger the developer base for iOS becomes. I can't see the downside to opening it.
That doesn't, however, mean they'll open it up on HN's preferred schedule.
Apple is contributing heavily to LLVM and making the code open source. One easily visible example is Clang, a c/c++/obj-c compiler for LLVM, which is open-source and pretty much created and maintained by Apple:
Certainly true, but what I'm getting at is, the decision not to close up an open-source project is rather different than the decision to open up a closed-source project. I'm not saying Apple has never contributed to open-source, but that I don't think their decision to heavily support an existing open-source project really reflects on what they'll do with Swift.
If people start adopting a cross-platform subset of Swift, and Apple adds features to Swift which objectively require special platform support (and other platforms don't have it), people will not adopt these innovations in their apps even when targeting Apple platforms, out of fear their previously cross-platform Swift code will no longer be cross-platform.
This effect ties Apple's hands behind their back in their ability to guide and steer the platform's evolution going forward. They'll be adding improvements and no one will be using them.
Of course, since Swift is so tightly integrated with Objective-C and Cocoa already, Swift is already quite Apple-specific. And that's what Apple really needs. A good language that makes sense for their platforms. We already have various incarnations of Mono and Java and what not compiling to iOS if people want cross-platform code.
But the lesson is there are always two sides of the coin here. Remember when Android being "open" had no downsides, either? Witness the malware, fragmentation, and Google having to write really nasty contracts with their OEMs in order to be able to steer the platform in the right direction for Android's own good.
Apple providing open source contributions or products doesn't mean they have a desire to do so. I don't imagine they set out to provide an open source product. Rather, they build out a product, and decide that it's in it's best interest to open source this part of it. I think that's an important distinction.
Even when they've expressed desire publicly to make something open, what it means to Apple doesn't exactly mean the same thing to the rest of the computing world.
I don't see how this meshes with the facts of the matter. The line of thinking that leads you to the conclusion "Apple will surely open-source Swift" could just as easily lead one to the conclusion "Apple has surely already promised to open-source Swift," which is obviously not correct.
The fact of the matter is that they haven't and haven't expressed any interest whatsoever in doing so. The fact that it has no downsides for them and that keeping it closed will alienate people has clearly not been a compelling reason to even talk about open-sourcing Swift up to this point. So the question is, what would cause it to become compelling to Apple in the future?
I don't think it's impossible that Apple would open-source it, but I don't think the evidence clearly points in that direction.
If some solution for Swift-on-the-server came out, it'll probably have to be OS X-only; as, as far as I know Swift is OS X* only. Such a dependency on OS X is not feasible, as OS X adds dependency to Apple hardware, rendering the platform infinitely expensive and unportable.
I reckon that it would be the best bet for Apple to open source Swift, as it would allow a much more lively community and a much bigger set of libraries around the language. They need not open-source the OS X-specific libraries, but a closed source Swift will not succeed to survive in any area other than OS X/iOS GUI development.
Swift is a LLVM frontend, as long it does compiles source code to the LLVM-IR, all of the LLVM "ecosystem" in the backend applies here.. so its pretty much multiplatform by now, since LLVM compiles to virtually all platforms and OS's..
Only Apple specific Api's wouldnt be available.. but even this.. there are always obj-c clones here and there for the apis..
So once they release the source for the Swift frontend, the possibilities for the Swift code are endless
The Swift standard library is Cocoa. Swift might be able to compile for all platforms through LLVM, but without the runtime and standard library, what use is the compiled code?
1. You could write an OS X application for your back end services, and use a OS X hosting company (there are some) or use a mac mini, etc. in a colo rack. But, you would not have a rich server side software tools infrastructure like JBoss, Tomcat, Yesod, etc.
2. use another language like Haskell, Java, etc. on the server.
56 comments
[ 6.2 ms ] story [ 120 ms ] threadhttp://www.macosforge.org/
https://opensource.apple.com/
Apple is definitely not afraid of closed source when it suits them (no source code available for most system APIs or bundled apps) but they also have a fairly extensive open source portfolio.
While WebObjects is still apparently being used by Apple's Online store and presumably some other internal applications, I wouldn't expect any serious WebObjects integration for Swift from Apple.
Then they point out that there are 3rd party HTTP libraries, and completely ignore the possibility that maybe Swift might be just the thing to catalyze the creation of a new one.
To be sure, unless you're serving from an OS X based server, it'll be hard to deploy Swift-based apps until significant supporting infrastructure has been built. But I don't see any real evidence that "never" is the answer to "When Can I Code Swift on the Server?"
What we really need is another one so that we can spend our time poking at a new language instead of building useful things! Swift would be an especially good one, since it doesn't have anything new to offer (unlike Clojure or Scala or Rust or Go) and it has great interoperability with Objective C (which Apple abandoned for server side programming in like 2005) AND it doesn't run on anything other than OSX, which is awesome because Apple discontinued Xserve over 10 years ago (EDIT: Xserve discontinued a few years ago), and there are basically no hosting providers of any kind. We could spend literally tens of person years building up all that stuff instead of using the massive infrastructure already in place!
How about "Yet Another Syntax Without Any Interesting Semantics, With a Bonus of Being Proprietary" (YASWAISWBBP)
You don't use a drill because of how interesting it is that the shape of the drill bit combined with its rotation lift material out of the hole. You do it because it works, and is efficient. A programming language is a tool, not a toy.
And no, neither Haskell nor Common Lisp are anywhere in the same city as the mainstream. For an idea of what I mean, pick a reasonably significant "target domain" for the language and consider how many major applications are written in that language. There is no platform on which Haskell or Common Lisp get used very much compared to other languages. Objective-C is clearly a dominant presence on iOS, C# rules Windows, Java has a lock on the enterprise, C and C++ are the bosses of systems programming, Haskell is…an interesting language whose motto is "avoid success at all costs."
And also, I don't think Common Lisp has enforced option types. (car '(1)) is 1 while (cadr '(1)) is NIL. Am I mistaken?
> [Swift is] the primary language for a huge platform. I don't know how much more mainstream you can get. This seems a bit like saying, "I'm not sure the newly elected US president is a significant figure in US politics."
> For an idea of what I mean, pick a reasonably significant "target domain" for the language and consider how many major applications are written in that language. There is no platform on which Haskell or Common Lisp get used very much compared to other languages. Objective-C is clearly a dominant presence on iOS, C# rules Windows, Java has a lock on the enterprise, C and C++ are the bosses of systems programming, Haskell is…an interesting language whose motto is "avoid success at all costs."
Rust does not fit into this concept of "mainstream." It is a forgone conclusion that many iOS 8 apps will be written in Swift. Rust has no niche yet.
Don't worry about tens of person years, there are more than enough developers who could use the attention.
No.
Additionally, since the compiler is built with LLVM if Apple were to open up the language there is a strong probability that it could run on any platform LLVM supports. The main piece holding it back would be that it seems to be pretty strongly tied to CoreFoundation. Apple has a .ddl for CoreFoundation on windows though so that may not hold Swift back from being cross-platform.
"We don't have anything to say about that at this point [...]"
http://article.gmane.org/gmane.comp.compilers.clang.user/493
And...
"Right now we are focused on finishing it up for the final release this fall."
https://twitter.com/clattner_llvm/status/473907124288770050
But another aspect of how Apple works is that they love secrecy and hate making promises. They built an ARM64 backend for LLVM in private, and the first time anyone found out it existed was when they announced the iPhone 5S with an ARM64 CPU. They still ended up releasing the source code.
Right now, even the Swift compiler binary isn't publicly available. You have to have a paid developer membership to obtain it. They wouldn't open the source at this stage regardless. They most likely will, but they also most likely won't commit to anything until the initial public release.
https://news.ycombinator.com/item?id=7853131
This trope drives me nuts. Go here: http://www.opensource.apple.com
You'll find a bunch of open-source projects that Apple has contributed code to (LLVM, WebKit, CUPS), as well as a bunch that they wrote and released (launchd, clang). They've recently released their ARM64 backend for LLVM.
I will be surprised—extremely so—if Apple choose not to open-source Swift. It has no downsides for them, and it's obvious that many people will simply refuse to get involved with it if they don't.
I agree with your prediction about Swift being open sourced. Among other things: as nice as Swift might be, its #1 value proposition is "easy to build iOS applications in", so the more people using it the bigger the developer base for iOS becomes. I can't see the downside to opening it.
That doesn't, however, mean they'll open it up on HN's preferred schedule.
http://llvm.org/devmtg/2007-05/09-Naroff-CFE.pdf
If people start adopting a cross-platform subset of Swift, and Apple adds features to Swift which objectively require special platform support (and other platforms don't have it), people will not adopt these innovations in their apps even when targeting Apple platforms, out of fear their previously cross-platform Swift code will no longer be cross-platform.
This effect ties Apple's hands behind their back in their ability to guide and steer the platform's evolution going forward. They'll be adding improvements and no one will be using them.
Of course, since Swift is so tightly integrated with Objective-C and Cocoa already, Swift is already quite Apple-specific. And that's what Apple really needs. A good language that makes sense for their platforms. We already have various incarnations of Mono and Java and what not compiling to iOS if people want cross-platform code.
But the lesson is there are always two sides of the coin here. Remember when Android being "open" had no downsides, either? Witness the malware, fragmentation, and Google having to write really nasty contracts with their OEMs in order to be able to steer the platform in the right direction for Android's own good.
Even when they've expressed desire publicly to make something open, what it means to Apple doesn't exactly mean the same thing to the rest of the computing world.
The fact of the matter is that they haven't and haven't expressed any interest whatsoever in doing so. The fact that it has no downsides for them and that keeping it closed will alienate people has clearly not been a compelling reason to even talk about open-sourcing Swift up to this point. So the question is, what would cause it to become compelling to Apple in the future?
I don't think it's impossible that Apple would open-source it, but I don't think the evidence clearly points in that direction.
I reckon that it would be the best bet for Apple to open source Swift, as it would allow a much more lively community and a much bigger set of libraries around the language. They need not open-source the OS X-specific libraries, but a closed source Swift will not succeed to survive in any area other than OS X/iOS GUI development.
* ... and iOS.
Only Apple specific Api's wouldnt be available.. but even this.. there are always obj-c clones here and there for the apis..
So once they release the source for the Swift frontend, the possibilities for the Swift code are endless
1. You could write an OS X application for your back end services, and use a OS X hosting company (there are some) or use a mac mini, etc. in a colo rack. But, you would not have a rich server side software tools infrastructure like JBoss, Tomcat, Yesod, etc.
2. use another language like Haskell, Java, etc. on the server.