That is wrong and not what was said: On a special computation (not named) Obj-C was 2,8 times faster than Python and Swift 3,9 times faster than Python, so the speedup in that special case is 1,4 times faster than Obj-C.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Announces Significant SDK Improvements with New 'Swift' Programming Language, CloudKit and More
- Thread starter MacRumors
- Start date
- Sort by reaction score
That is wrong and not what was said: On a special computation (not named) Obj-C was 2,8 times faster than Python and Swift 3,9 times faster than Python, so the speedup in that special case is 1,4 times faster than Obj-C.
This reminds me of a 'better' language..
Similar to a transition from Visual Basic 6 to VB.NET, the only difference here, is Apple's bring the two together .. o can use both old, and new code..
Try doing that in .NET .... Not possible.
I like the preview and the fact it catches errors as you type... This would be a time saver for anyone...
(not me) but all of YOU guys
Similar to a transition from Visual Basic 6 to VB.NET, the only difference here, is Apple's bring the two together .. o can use both old, and new code..
Try doing that in .NET .... Not possible.
I like the preview and the fact it catches errors as you type... This would be a time saver for anyone...
(not me) but all of YOU guys
Then simply use the Language Reference that Apple put into the iBook store for free. It is well written and enough for anyone knowing how to code already.
https://developer.apple.com/swift/
There is a link to the online docs and the iBook guide there.
https://developer.apple.com/swift/
There is a link to the online docs and the iBook guide there.
Thanks for the clarification.
We need more benchmarks to judge how performance might change in other circumstances. It won't make much difference for some apps I've worked on, but for others a performance jump could be a huge benefit.
I don't code but I love the old easter eggs. Kinda sorta.
var occupations = [
"Malcolm": "Captain",
"Kaylee": "Mechanic",
]
occupations["Jayne"] = "Public Relations
Excerpt From: Apple Inc. The Swift Programming Language. iBooks. https://itun.es/us/jEUH0.l
----------
var occupations = [
"Malcolm": "Captain",
"Kaylee": "Mechanic",
]
occupations["Jayne"] = "Public Relations
Excerpt From: Apple Inc. The Swift Programming Language. iBooks. https://itun.es/us/jEUH0.l
----------
I think I now know why Apple is claiming such dramatic performance improvements (admittedly in a few specific areas). Chris Lattner was the guy who basically created this language. He's the one who also created LLVM and clang. When you've got Chris Lattner developing a new language designed to compile with LLVM and clang, you're pretty much assured to get better code optimization with those same tools than a computer language from the 80s.
That seems quite feasible - however, I suspect that there would be a lot of resistance to wider adoption as long as Apple were seen as controlling/owning the language. Witness: Google vs. Oracle over Java (despite there being open source Java implementations) and the fact that C# hasn't seen much adoption outside of Windows.
Agree that's never going to happen.
No they wouldn't. Swift sounds as if it can link with existing C libraries. If you stick to POSIX and other widely-implemented APIs then you can easily write software that runs on anything from an IBM mainframe to a Raspberry Pi with minor tweaks. You've got things like OpenGL for graphics, OpenCL for number crunching, Qt or X11 for GUI.
At one point, Microsoft actually ported its Microsoft Foundation Classes API to (classic) MacOS so you could build Visual C/C++ for Macintosh.
The problem is the GUI (which is mainly what Cocoa does): Apps written with cross-platform GUIs always end up feeling a bit clunky compared with something written in the native GUI. The answer is to make sure that your app uses a fronted/backend design, so you can share as much code as possible between platforms. However, what that's likely to mean is that - like Objective C before it - Swift only ever gets used for OS X front-ends to C/C++ code.
You've obviously lost touch with browser-based programming. With HTML5 and related technologies the Browser Window is now virtually a complete operating system, with standard APIs for 2D and 3D graphics, vector graphics, media playback and local data storage. JS "interpreters" are now highly optimized just-in-time compilers with pretty amazing performance for a 'scripting language'. People can and do write games and office apps (notably Google Docs) that run in Javascript. The main restriction is access to 'local' resources - and that's because browser windows are heavily sandboxed, not because Javascript can't do it.
If you do need native resource access, there's Node.JS (lets you run Javascript outside a browser, and bind to native APIs, mainly used for server-side programming... or even writing servers) or you can bundle your JS code with a customised Mozilla or Chrome 'runtime' to produce something like a normal application (see GitHub's new 'Atom' text editor for an example).
Go look at Google Web Toolkit. Write in Java - using the GWT API - and 'compile' to highly optimised, minified Javascript.
Then there's Dart - again from Google - as well as CoffeeScript, Haxe and possibly others that 'compile' to javascript to take advantage of the cross-platform nature of web browsers.
There's even asm.js - a pared-down subset of Javascript specifically designed to be generated by 'compiling' other languages.
Noob question here.
So what does this mean for Darwin, and all the other open source pinnings of OS X? Will they eventually port everything to swift? Or keep the C/Obj-C code base while user level apps are developed using swift?
I ask because I was thinking on hacking on Darwin (or PureDarwin although it's dead?) as a side hobby so i was wondering what direction apple will take for their Unix base. I'm particularly interested in lower level/server related stuff, and might eventually get into OS X App development. I'm particularly interested in the Unix workings of OS X also.
Thanks
PS. No, I will not work on Linux. I'm not particularly fond of that crowd for devving.
So what does this mean for Darwin, and all the other open source pinnings of OS X? Will they eventually port everything to swift? Or keep the C/Obj-C code base while user level apps are developed using swift?
I ask because I was thinking on hacking on Darwin (or PureDarwin although it's dead?) as a side hobby so i was wondering what direction apple will take for their Unix base. I'm particularly interested in lower level/server related stuff, and might eventually get into OS X App development. I'm particularly interested in the Unix workings of OS X also.
Thanks
PS. No, I will not work on Linux. I'm not particularly fond of that crowd for devving.
Last edited:
It's becoming quite a pattern: One year Android (not just Google but also Samsung with their TouchWiz BS) adds some half-baked features without thinking about the implications of how it affects the entire systemdisregarding how frivolous some of them may be. The next year Apple implements a fully realized solution to a problem that actual users are facing that integrates seamlessly into the operating system from the bottom up while following the design guidelines that keep iOS looking amazing. Ice the cake with a few features that are super useful that Android doesn't have like intelligent responses to messages, continuity, a crazy fast gaming framework, a slick new method of sending audio messages, and a modern, easier to use programming language (not some Java ripoff) to make it all happen.
People are underestimating how big of a deal Swift is. It might be the biggest announcement of the conference, and has the longest-lasting effect on the future of Apple's platform.
Another pattern: Google debuting great cloud applications, followed by Apple finally starting to get what the cloud is with some half-baked solutions. Apple seems to be catching up quickly but the proof will be in the pudding and iOS 8 hasn't shipped yet. But I do desperately hope Apple improves in the cloud because I have concerns about using software that trades privacy for getting something free. I'm not particularly fond of whoring out my very person. If it works like the stage demo then they are well on their way to finally putting up a fight against Google. But don't expect Google to sit still either. I'm also very interested in the rumored search technology that Apple is working on that might debut at the end of next year.
People are underestimating how big of a deal Swift is. It might be the biggest announcement of the conference, and has the longest-lasting effect on the future of Apple's platform.
Another pattern: Google debuting great cloud applications, followed by Apple finally starting to get what the cloud is with some half-baked solutions. Apple seems to be catching up quickly but the proof will be in the pudding and iOS 8 hasn't shipped yet. But I do desperately hope Apple improves in the cloud because I have concerns about using software that trades privacy for getting something free. I'm not particularly fond of whoring out my very person. If it works like the stage demo then they are well on their way to finally putting up a fight against Google. But don't expect Google to sit still either. I'm also very interested in the rumored search technology that Apple is working on that might debut at the end of next year.
We have yet to see how the new iCloud stuff works. iCloud still isn't useful for syncing local files the seamless way Dropbox is, for example.
That's a fair point.
All very well, except that JavaScript in UIWebView is hindered when it comes to being highly optimised and high performance because of the lack of Nitro. Admittedly interoperability between JavaScript and obj-c has been easier since iOS 7, but that's through undocumented APIs (JavaScriptCore) and so not exactly easy. If everything was going to go to JavaScript, surely UIWebView wouldn't be hindered by performance issues (see the example of Facebook going native) and would have become the defacto interface for app development.
As for GWT, Dart etc - maybe it's me but I don't really see GWT as a means to better cross compatibility, it seems more of a way to allow people who don't know JavaScript to write code that runs natively in a browser. I'm not saying that's a bad thing, but surely not a positive step towards a common development platform. Dart's stated goal is to replace JavaScript, and only 'compiles' to JavaScript because that is the only option to have Dart code running in a browser. To quote the Wikipedia page:
By the way, I spend at least 40% of my time on web app front end development and another 40% of my time on server side development in a number of environments (including Node.JS) - I've definitely not lost touch with browser based programming!
Not really a noob question. I'd say that's the same question on the minds of just about all the non-noobs, too.
The fact is, nobody outside of Apple really knows. The introduction of Swift may very well indicate that Apple intends to write a new kernel in Swift and OS 11 is just around the corner. I might also indicate they're just going to write a bunch of apps in Swift and leave all the lower level stuff alone.
True - but that's an Apple-specific shortfall that really should have been fixed by now. As I mentioned, outside iOS there are other options like bundling with a Chromium or Mozilla runtime.
I really mentioned those as proof-of-concept that you could 'compile' other languages to Javascript. Also, although Javascript is a pretty powerful and flexible language, it does have some shortfalls when it comes to larger projects: some people won't touch a duck-typed language with a bargepole, for instance (and part of me agrees), and browser-based Javascript doesn't have a proper modules system (although there are 101 ways of simulating one). GWT also deals with a lot of browser incompatibilities for you (another big drawback of Javascript, although its getting much better now with newer browsers).
Also, although mixing languages is quite possible, it does keep things simple to have one language across a project (speaking as someone who at one stage ended up with a project mixing ActionScript, Javascript and PHP...)
Only thing that puts me off GWT, Dart (or Go, but that's a bit offtopic) is lack of confidence that Google will still be supporting them in 2 years' time, given their track record of dropping projects at short notice.
Don't hold your breath waiting for Internet Explorer and Safari to support native Dart...
Well I tried out Xcode 6 and Swift and it's quite buggy. Also looks like some Swift features aren't even implemented yet. I would suggest anyone who hasn't tried it yet, wait at least until there's a new version of the Xcode 6 beta.
Why would I get out of my "consumer mindset" when Apple is first and foremost a consumer company?
Swift definitely seems like the best and most important part of the whole presentation. It's rather exciting, and this language looks superbly easy to use for those with java and c/c++ backgrounds.
Objective C was a tough one for me to get my head around the syntax, but this one (so far) makes a lot more sense.
Of course, I can also note why this wasn't as front page as the other information released. Most of *why* this is super-exciting only makes sense to code developers. Right in the presentation, the presenter mentioned that some of the things they said, you have the non-programmers going "Huh? What are they clapping about?"
But for me, perhaps I can wrap my mind around the syntax better because it's a lot closer to programming languages I'm familiar with.
Objective C was a tough one for me to get my head around the syntax, but this one (so far) makes a lot more sense.
Of course, I can also note why this wasn't as front page as the other information released. Most of *why* this is super-exciting only makes sense to code developers. Right in the presentation, the presenter mentioned that some of the things they said, you have the non-programmers going "Huh? What are they clapping about?"
But for me, perhaps I can wrap my mind around the syntax better because it's a lot closer to programming languages I'm familiar with.