I was actually always expecting them to "open source" swift the language -- I am just surprised that it came this year.
Chris Lattner, when asked this question, had always indicated that it was not right now but that it could in the future (he did not rule it out). When he was developing the LLVM (think of it as a high level transportable assembler/optimizer that allows languages to generate one meta-assembly language and the LLVM would take it to x86 or ARM -- or others in the future) -- he had contacted Apple about Objective-C questions. Apple apparently thought it was a good idea so they hired him -- and the LLVM would continue being open. Apple moved over all their compiler environments from older gcc stuff to the LLVM c-lang compilers. Apple then built the Swift language also on the same platform. I got the impression that there was always an understanding between Apple and Chris that the compiler technology would be open (just a feeling).
Google is basing all their Chromium stuff on LLVM and has all of it moved to that for Apple and for Linux -- with Windows being worked on. In fact Google is already a fair bit along on LLVM for Visual Studio - the only issues remaining were really just interoperability between object-code on the newest microsoft compilers. In fact Google's LLVM technology was built to install into Visual Studio itself.
Microsoft only recently started moving the same direction the rest of the industry was moving. Now if we could only get Microsoft to move the kernel and shell to be "almost unix" so that Cygwin etc was not needed and I could drop into a nice bash shell I would be happier with them.
There hasn't been a SCOTUS ruling yet on whether they'll accept Google's case. You may have confused things with the governments statement that they would not recommend they accept it. IMO it's unlikely the Supreme Court will hear it but they could.
That would be a disaster since up until now languages have not been copyrightable, but if they allowed the copyrighting of API's it would have the same effect. It would also cause a lot of collateral damage that goes far beyond just Google vs Oracle. It would also be hypocritical to go after hardware suppliers that try and lock you into specific supplies (think printer cartridges with DRM modules) and in the past IBM for preventing 3rd party hardware manufacturers building devices to install in IBM hardware because it was anticompetitive and damaging to market competition.... while allowing exactly the same thing through the copyrighting of APIs themselves.
You are assuming that just because scripts written in Java or Flash are insecure that scripts written in Swift will be insecure -- that need not be true! And the fact that they are compiled makes reverse engineering them more difficult.
Because in complied code you don't know what is in there. Look at all the malicious coders that try to slip stuff through the App Store with tricky things like hiding attacks behind time disabled features and other disguised malware. Apple doesn't catch them all.
There are ways to detect what Javascript is trying to do, like malicious stuff, which is why Google can detect a malware web page before it loads.
Quote:
I hadn't really considered using Swift to develop a replacement for a web server like Apache -- but it would be worth considering if the result was better performing and more maintainable than the current offering.
A dedicated Swift server is the only way you would be able to run server-side Swift code regardless whether the server itself was written in Swift or C++. The server needs to understand Swift. It is similar to why server-side Javascript usually runs in a Java servlet environment.
Sure. Like Google decided to write their own language for Android when they were deciding between C# or Java.
Oh wait, they didn't create their own, and that's why they're in trouble with Oracle.
Java in Android predates the Google purchase. The choice of Java in Android was to copy the Java-based BlackBerry, along with all the other J2ME phones (Nokias) in existence in that time.
How will this benefit Apple users in the long run? Isn't this usually a sign that Apple is not going expand upon the language anymore and let third parties take the lead?
This isn't directly going to benefit Apple users at all, this is mostly about allowing other developers to become familiar with the language outside of Apple's platforms. Personally, I believe this announcement is Apple's first step in getting Swift onto the web as an alternative to JavaScript. Next year we'll see SwiftCore made available as part of Webkit.
by becoming an open source and standard language -- it can assume another roll ...
The roll of a client-side and server-side scripting language to replace JavaScript.
Not only that, these same scripts can be compiled -- providing better performance, secure code -- all while using less bandwidth.
It won't be long before we see browsers supporting (first, interpreted then) compiled Swift scripts.
This changes everything!
I seem to have heard or read that one of the one of the platforms available for developing with Swift will be iOS!
I perked up when they announced at the Keynote that they've rewritten the Safari browser in Metal - now it's faster and occupies less space... I assume that Metal, which will likely remain exclusive to Apple, is even a bigger deal than Swift... but what do I know; I'm so far behind the leading edge in programming I can't even see the dust of the trailing laggards.
This isn't directly going to benefit Apple users at all, this is mostly about allowing other developers to become familiar with the language outside of Apple's platforms. Personally, I believe this announcement is Apple's first step in getting Swift onto the web as an alternative to JavaScript. Next year we'll see SwiftCore made available as part of Webkit.
If they wanted to get Swift onto the web all they have to do is support google's old effort to get NACL/pNACL supported in web browsers other than just Chrome. Added it to Safari, make a nice contribution to the foundation responsible for Firefox and change their minds into supporting it. Then any language based on LLVM tech can be run in the browser and run in a sandboxed LLVM vm that will give rights secure/limited resources to run.
How will this benefit Apple users in the long run? Isn't this usually a sign that Apple is not going expand upon the language anymore and let third parties take the lead?
When Swift was announced there was some discussion about the language evolving for a while yet with a lot happening in the next two years... one of which has now passed. I don't see Apple letting the language evolve willy-nilly...
I perked up when they announced at the Keynote that they've rewritten the Safari browser in Metal - now it's faster and occupies less space... I assume that Metal, which will likely remain exclusive to Apple, is even a bigger deal than Swift... but what do I know; I'm so far behind the leading edge in programming I can't even see the dust of the trailing laggards.
It is a performance improvement for graphics applications on Mac OS X but something that is proprietary is not necessarily good for a lot of games since we all know the "gaming" operating system of preference is Windows (meh! - luckily I am not a gamer).
We'll see how swift develops. Java is a hog for resources, and Apple devices cannot support java. One might need to think of Swift as a Java alternative.
If they wanted to get Swift onto the web all they have to do is support google's old effort to get NACL/pNACL supported in web browsers other than just Chrome. Added it to Safari, make a nice contribution to the foundation responsible for Firefox and change their minds into supporting it. Then any language based on LLVM tech can be run in the browser and run in a sandboxed LLVM vm that will give rights secure/limited resources to run.
That project was to allow the execution of native binary code within the browser. That's not at all what I was talking about. I'm talking about using the Swift language as a scripting language as an alternative to JavaScript.
It would seem that this is the direction Apple may want to go taking into account their desire to match iCloud apps with native apps.
That project was to allow the execution of native binary code within the browser. That's not at all what I was talking about. I'm talking about using the Swift language as a scripting language as an alternative to JavaScript.
It would seem that this is the direction Apple may want to go taking into account their desire to match iCloud apps with native apps.
The question is WHY would they want to run "native" code in a browser. The reason is that instead of locking a browser into a specific scripting language, any language would be able to be run in a browser. You could run C, C++, Swift, Rust, etc. as your logic in your application. All of the languages would have access to "services" (similar to the way an operating system works) -- so it would be able to manipulate the DOM in the browser, it would be able to use OpenGL or whatever graphics are given to draw in a "canvas" area. You would be able to click on a an area and the event could run any language. You could take specialized algorithms and port them into the browser without rewriting them etc. It was a way of trying to open up the browser to competing (scripting) languages without getting agreement of which one it was other than LLVM object code. You would not be running natively on the operating system, but in a sandbox within the browser that would have much more restrictions on what you could access (similar to other languages).
My take away at that time was they would use it to write and compile future OS X, but that OS X would still use UNIX core libraries and kernel. The fact that they are extending Swift to Linux means to me that UNIX will be around a while longer at Apple.
your whole comment has me confused.
You are aware, that from the OS level, iOS and Mac OS X are esentially the same. Down to the XNU Kernel. The GUI and API parts have the greatest differences.
This is me ssh'ed/logged into my iPad Mini 2 running 7.0.4.
You are aware, that from the OS level, iOS and Mac OS X are esentially the same. Down to the XNU Kernel. The GUI and API parts have the greatest differences.
This is me ssh'ed/logged into my iPad Mini 2 running 7.0.4.
Even if Mac OS X disappeared from Apple tomorrow, the i-devices would still have all the Darwin code, XNU kernel, and BSD style userland.
That flew over my head until you responded. Yes, OS X is UNIX (certified) of the BSD flavour. It has a proprietary UI on it.
In fact the reason I finally made the jump from "Windows" (Linux prefered) was that I was buying bleeding edge laptops for work (Windows) and trying to install Linux on it.... but often the driver or configuration support was lacking for the newest of the new laptops and it was just an absolute pain. The better alternative was to buy a "UNIX" laptop that just worked.... and that was an Apple laptop... which I could also install windows on if I needed to use it for work stuff that would not run on "OS X". Now I have no use for any windows stuff, but it I do still use VMWare to run Linux and an Oracle Database under Linux (works amazingly well for development purposes.
I had earlier experience with Apple laptops that one of my customers gave me for their work -- before OS X... and although I liked it.... it was not until they rewrote their UI on-top of UNIX that I became seriously interested in it.... Just wish that Windows would at least make their operating system "UNIX" compatible (for compiling stuff) and a nice bash shell ... instead of forcing people to cludge things in like Cygwin....
The best decision Apple ever made was replacing their old primitive kernel with a fully multitasking/multiuser UNIX kernel.
A dedicated Swift server is the only way you would be able to run server-side Swift code regardless whether the server itself was written in Swift or C++. The server needs to understand Swift. It is similar to why server-side Javascript usually runs in a Java servlet environment.
I don't know where you get this stuff ... php, for example, runs server-side on any 'Nix server.
Here's a quote from StackOverflow:
Can you use Swift as a web programming language?
Swift works just perfect as a web programming language. You can do python like scripting (for rapid development or simple tasks) and later compile the same code with XCode (for speed):
Copy the following script to /Library/WebServer/CGI-Executables/TestCGI on your Mac (OSX Mavericks or Yosemity with XCode 6.x installed). Make executable with chmod +x TestCGI. With httpd started call http://localhost/cgi-bin/TestCGI. You will get the call parameters echoed...
#!/usr/bin/env xcrun swift
import Foundation
println("Content-Type: text/html")
println("Content:")
println("")
println("1. Process.argument(s):<br />")
for s in Process.arguments {
println(s + "<br />")
}
println("<br />")
let env: Dictionary = NSProcessInfo().environment
if let requestMethod: Optional = env["REQUEST_METHOD"] {
println("2. Request method is: \(requestMethod!)<br /><br />")
}
println("3. Number of environment variables: \(env.count)<br /><br />")
println("4. List environment:<br />")
for key in env.keys {
println("\(key) == \(env[key]!)<br />")
}
Several of the answers, though, are over-complicating the question as are you.
FWIW, Years ago, a fellow ColdFusion developer and I, were able to configure and run a total CFMX environment from a CD ... Web Server, Web Application Server, CFMX (Blue Dragon) an SQL DB, CFMX apps and data.
On the CD the system was read-only ... but if you copied the CD to the desktop it was read-write. (With the CF implementation, you could drop into the OS, e.g. Terminal, and copy the CD (or just the DBs) to the desktop from a CF app we provided) ... Drop Dead simple!
The reasoning behind the implementation was that a CF developer could strut his stuff by sending a CD to a ponteial client.
Our implementation and writeup is lost to history -- but I found this, which followed the same approach we used -- for the same reasons.
Back to running Swift on Apache ... I'm in the middle of a long install with lots of distractions (doctors appointments, air conditioner out ...). Anyway, as soon as convenient, I'll try running Swift on Apache as per the StackOverflow answer.
Java in Android predates the Google purchase. The choice of Java in Android was to copy the Java-based BlackBerry, along with all the other J2ME phones (Nokias) in existence in that time.
Tell that to Andy Rubin, who e-mailed Eric Schmidt before the Android purchase:
Quote:
If Sun doesn’t want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language, or 2) Do Java anyway and defend our decision, perhaps making enemies along the way.
When the purchase was made is irrelevant. Google knew before the purchase there was no agreement in place with Sun regarding Java.
And as I stated before, Google is soon going to lose badly to Oracle when everything is finished. As it should be. Better for the software industry as a whole.
Comments
VERY good observation. The copiers have been revved up just waiting for the swift shoe to drop.
There hasn't been a SCOTUS ruling yet on whether they'll accept Google's case. You may have confused things with the governments statement that they would not recommend they accept it. IMO it's unlikely the Supreme Court will hear it but they could.
That would be a disaster since up until now languages have not been copyrightable, but if they allowed the copyrighting of API's it would have the same effect. It would also cause a lot of collateral damage that goes far beyond just Google vs Oracle. It would also be hypocritical to go after hardware suppliers that try and lock you into specific supplies (think printer cartridges with DRM modules) and in the past IBM for preventing 3rd party hardware manufacturers building devices to install in IBM hardware because it was anticompetitive and damaging to market competition.... while allowing exactly the same thing through the copyrighting of APIs themselves.
You are assuming that just because scripts written in Java or Flash are insecure that scripts written in Swift will be insecure -- that need not be true! And the fact that they are compiled makes reverse engineering them more difficult.
Because in complied code you don't know what is in there. Look at all the malicious coders that try to slip stuff through the App Store with tricky things like hiding attacks behind time disabled features and other disguised malware. Apple doesn't catch them all.
There are ways to detect what Javascript is trying to do, like malicious stuff, which is why Google can detect a malware web page before it loads.
Quote:
I hadn't really considered using Swift to develop a replacement for a web server like Apache -- but it would be worth considering if the result was better performing and more maintainable than the current offering.
A dedicated Swift server is the only way you would be able to run server-side Swift code regardless whether the server itself was written in Swift or C++. The server needs to understand Swift. It is similar to why server-side Javascript usually runs in a Java servlet environment.
"Open source" is a noun, not a verb.
Everything gets verbified if you're not careful.
Everything gets verbified if you're not careful.
Right you are ... and "open source" is near the top of the list of nouns that should be verified :=)
Sure. Like Google decided to write their own language for Android when they were deciding between C# or Java.
Oh wait, they didn't create their own, and that's why they're in trouble with Oracle.
Java in Android predates the Google purchase. The choice of Java in Android was to copy the Java-based BlackBerry, along with all the other J2ME phones (Nokias) in existence in that time.
How will this benefit Apple users in the long run? Isn't this usually a sign that Apple is not going expand upon the language anymore and let third parties take the lead?
This isn't directly going to benefit Apple users at all, this is mostly about allowing other developers to become familiar with the language outside of Apple's platforms. Personally, I believe this announcement is Apple's first step in getting Swift onto the web as an alternative to JavaScript. Next year we'll see SwiftCore made available as part of Webkit.
I perked up when they announced at the Keynote that they've rewritten the Safari browser in Metal - now it's faster and occupies less space... I assume that Metal, which will likely remain exclusive to Apple, is even a bigger deal than Swift... but what do I know; I'm so far behind the leading edge in programming I can't even see the dust of the trailing laggards.
This isn't directly going to benefit Apple users at all, this is mostly about allowing other developers to become familiar with the language outside of Apple's platforms. Personally, I believe this announcement is Apple's first step in getting Swift onto the web as an alternative to JavaScript. Next year we'll see SwiftCore made available as part of Webkit.
If they wanted to get Swift onto the web all they have to do is support google's old effort to get NACL/pNACL supported in web browsers other than just Chrome. Added it to Safari, make a nice contribution to the foundation responsible for Firefox and change their minds into supporting it. Then any language based on LLVM tech can be run in the browser and run in a sandboxed LLVM vm that will give rights secure/limited resources to run.
When Swift was announced there was some discussion about the language evolving for a while yet with a lot happening in the next two years... one of which has now passed. I don't see Apple letting the language evolve willy-nilly...
I perked up when they announced at the Keynote that they've rewritten the Safari browser in Metal - now it's faster and occupies less space... I assume that Metal, which will likely remain exclusive to Apple, is even a bigger deal than Swift... but what do I know; I'm so far behind the leading edge in programming I can't even see the dust of the trailing laggards.
It is a performance improvement for graphics applications on Mac OS X but something that is proprietary is not necessarily good for a lot of games since we all know the "gaming" operating system of preference is Windows (meh! - luckily I am not a gamer).
Gee, and I was just listening to your podcast this morning where you were hoping that Swift would finally come out with "version 1."
Tells me that you guys haven't been paying attention at all.
I'm looking forward to compiling some of this on my Slackware system.
If they wanted to get Swift onto the web all they have to do is support google's old effort to get NACL/pNACL supported in web browsers other than just Chrome. Added it to Safari, make a nice contribution to the foundation responsible for Firefox and change their minds into supporting it. Then any language based on LLVM tech can be run in the browser and run in a sandboxed LLVM vm that will give rights secure/limited resources to run.
That project was to allow the execution of native binary code within the browser. That's not at all what I was talking about. I'm talking about using the Swift language as a scripting language as an alternative to JavaScript.
It would seem that this is the direction Apple may want to go taking into account their desire to match iCloud apps with native apps.
That project was to allow the execution of native binary code within the browser. That's not at all what I was talking about. I'm talking about using the Swift language as a scripting language as an alternative to JavaScript.
It would seem that this is the direction Apple may want to go taking into account their desire to match iCloud apps with native apps.
The question is WHY would they want to run "native" code in a browser. The reason is that instead of locking a browser into a specific scripting language, any language would be able to be run in a browser. You could run C, C++, Swift, Rust, etc. as your logic in your application. All of the languages would have access to "services" (similar to the way an operating system works) -- so it would be able to manipulate the DOM in the browser, it would be able to use OpenGL or whatever graphics are given to draw in a "canvas" area. You would be able to click on a an area and the event could run any language. You could take specialized algorithms and port them into the browser without rewriting them etc. It was a way of trying to open up the browser to competing (scripting) languages without getting agreement of which one it was other than LLVM object code. You would not be running natively on the operating system, but in a sandbox within the browser that would have much more restrictions on what you could access (similar to other languages).
My take away at that time was they would use it to write and compile future OS X, but that OS X would still use UNIX core libraries and kernel. The fact that they are extending Swift to Linux means to me that UNIX will be around a while longer at Apple.
your whole comment has me confused.
You are aware, that from the OS level, iOS and Mac OS X are esentially the same. Down to the XNU Kernel. The GUI and API parts have the greatest differences.
This is me ssh'ed/logged into my iPad Mini 2 running 7.0.4.
.....................................................
iPad:~ root# uname -a
Darwin iPad 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 27 23:08:32 PDT 2013; root:xnu-2423.3.12~1/RELEASE_ARM64_S5L8960X iPad4,5 arm64 J86AP Darwin
iPad:~ root#
.....................................................
Linux is not Unix. Linux is a Unix clone.
OTOH, Mac OS X is Unix
http://www.macnn.com/articles/07/08/02/leopard.unix.certified/
Even if Mac OS X disappeared from Apple tomorrow, the i-devices would still have all the Darwin code, XNU kernel, and BSD style userland.
your whole comment has me confused.
You are aware, that from the OS level, iOS and Mac OS X are esentially the same. Down to the XNU Kernel. The GUI and API parts have the greatest differences.
This is me ssh'ed/logged into my iPad Mini 2 running 7.0.4.
.....................................................
iPad:~ root# uname -a
Darwin iPad 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 27 23:08:32 PDT 2013; root:xnu-2423.3.12~1/RELEASE_ARM64_S5L8960X iPad4,5 arm64 J86AP Darwin
iPad:~ root#
.....................................................
Linux is not Unix. Linux is a Unix clone.
OTOH, Mac OS X is Unix
http://www.macnn.com/articles/07/08/02/leopard.unix.certified/
Even if Mac OS X disappeared from Apple tomorrow, the i-devices would still have all the Darwin code, XNU kernel, and BSD style userland.
That flew over my head until you responded. Yes, OS X is UNIX (certified) of the BSD flavour. It has a proprietary UI on it.
In fact the reason I finally made the jump from "Windows" (Linux prefered) was that I was buying bleeding edge laptops for work (Windows) and trying to install Linux on it.... but often the driver or configuration support was lacking for the newest of the new laptops and it was just an absolute pain. The better alternative was to buy a "UNIX" laptop that just worked.... and that was an Apple laptop... which I could also install windows on if I needed to use it for work stuff that would not run on "OS X". Now I have no use for any windows stuff, but it I do still use VMWare to run Linux and an Oracle Database under Linux (works amazingly well for development purposes.
I had earlier experience with Apple laptops that one of my customers gave me for their work -- before OS X... and although I liked it.... it was not until they rewrote their UI on-top of UNIX that I became seriously interested in it.... Just wish that Windows would at least make their operating system "UNIX" compatible (for compiling stuff) and a nice bash shell ... instead of forcing people to cludge things in like Cygwin....
The best decision Apple ever made was replacing their old primitive kernel with a fully multitasking/multiuser UNIX kernel.
I don't know where you get this stuff ... php, for example, runs server-side on any 'Nix server.
Here's a quote from StackOverflow:
http://stackoverflow.com/questions/24235974/can-you-use-swift-as-a-web-programming-language
Several of the answers, though, are over-complicating the question as are you.
FWIW, Years ago, a fellow ColdFusion developer and I, were able to configure and run a total CFMX environment from a CD ... Web Server, Web Application Server, CFMX (Blue Dragon) an SQL DB, CFMX apps and data.
On the CD the system was read-only ... but if you copied the CD to the desktop it was read-write. (With the CF implementation, you could drop into the OS, e.g. Terminal, and copy the CD (or just the DBs) to the desktop from a CF app we provided) ... Drop Dead simple!
The reasoning behind the implementation was that a CF developer could strut his stuff by sending a CD to a ponteial client.
Our implementation and writeup is lost to history -- but I found this, which followed the same approach we used -- for the same reasons.
Back to running Swift on Apache ... I'm in the middle of a long install with lots of distractions (doctors appointments, air conditioner out ...). Anyway, as soon as convenient, I'll try running Swift on Apache as per the StackOverflow answer.
Java in Android predates the Google purchase. The choice of Java in Android was to copy the Java-based BlackBerry, along with all the other J2ME phones (Nokias) in existence in that time.
Tell that to Andy Rubin, who e-mailed Eric Schmidt before the Android purchase:
When the purchase was made is irrelevant. Google knew before the purchase there was no agreement in place with Sun regarding Java.
And as I stated before, Google is soon going to lose badly to Oracle when everything is finished. As it should be. Better for the software industry as a whole.