When Can I Code Swift on the Server?
cabforward.com
cabforward.com
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.
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.
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?"
"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."
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.
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 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.
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.
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.