I completely disagree Swift VERY special. I'm a embedded systems programmer, and I most to use Swift. There is no other serious contender right now for a modern systems language than can replace C, C++ or objC.

Swift ia very unique language is that it:
1) Has the high level language syntactical goodness of a scripting language like Python or Ruby
2) Has the native performance of a systems language like C
3) Has strong support for multiple paradigms including Functional Programming, Object, and procedural
4) Can morph from a JIT language during compile time for faster programmer efficiency (Like Java), and compile fully native like C
5) Has a hot-coding environment like I've never seen anywhere else

There is only one language that come close to this, and that is Rust. But Rust is probably 5 years from being production ready. And it lacks the JIT-y hot coding goodness.

True. True. and True.

Having said that, I see a couple of things coming down the pike. First, Java usage have been in pretty steady continual decline since 2000 (Tiobe). In the last couple of years C has retaken the top spot. (though it is somewhat surprising that there hasn't been a noticeable bump upward in Java use since Android has taken off).

Universities are largely moving away from Java as a teaching language. It has moved very strongly to Python in the last few years. I suspect this is impacting Java usage quite a lot.

Refcounts don't kill the parallelism.

Apple went down the path of extensive parallelism using queue-based thread pools (libdispatch) several years ago... this is pretty optimal approach to concurrency. In C/C++/objC Apple added the extension for "blocks" to GCC and Clang which are the same thing as lambdas. Swift has the idea of lambdas built right in from the get-go. Libraries using libdispatch deep down, together with language hints that help autovectorization, make it so Swift enjoys parallel excution not unlike a functional language, but at native speed.

I don't see any support for your claim at all.

Apple has typically supported the last 3-4 generations of devices with new updates. iOS8 just released supports phones back to the 4s, which was released back in 2011. Given that *no other* manufacturer has anything close that kind of OS upgrade support history, I really don't see how you can knock Apple at all on this point. (if you compare the install rate you can get a good picture of this in 1 week iOS8 was installed on 50% of the user base, compared to just 25% of KitKat after 10 months)

These performance issue are huge! The Android team made the wrong choice with Java. essentially they have saddled Android with the need of 2-3x the CPU and 4X the RAM to do the same things as an iPhone. Not only does that cost money (and profit), but it sucks battery life, requiring bigger fatter batteries.

No doubt these are nice features. Which is why the hybrid approach of Swift is the best of both worlds. JIT live-code at development, compile time speed and memory footprint.

But some (like Linus T.) would also point-out this as a reason to keep programs in languages like 'C', it keeps the mid level programmers out who need more hand-holding.

Really? Your argument is we should waste CPU and RAM resources with inefficient languages, and try and make up for it with lots of hardware?

Every embedded system has these constraints, not just mobile phones. Welcome to the rest of the world.

For example. I recently got a Nexus 7 and benchmarked a javascript app against a 3 year old iPad2. 2x cores, 2x the GHz, 4x the Ram. The result? The Nexus 7 was unacceptably laggy in response to user touch and DOM manipulation... compared to a 3 year old iPad. Ridiculous!

Also, again, if you bother to read that article, there is no magic "throw more RAM at it" solution with systems on a chip. There are RAM limits to what can be integrated onto a SOC

If you'd bother to look at current Swift benchmarks, not the initial betas, you'd see it racing passed C code due to its inherent parallelism.

See: http://www.jessesquires.com/ap...

In a series of typical sort tests, Swift bests objC in these tests by 6-18 times, both using Clang & LLVM. Yikes!

Except it isn't. Go ahead a read: http://sealedabstract.com/rant...

Jump to the graph: "If you remember nothing else from this blog post, remember this chart."

I disagree. C++ is such a crazy language with so many nooks and crannies and 30 years of cruft, when we sit down to discuss what *shouldn't* be allowed in our programs (no boost, etc, etc)... we end up back at C with a few extras. It would be nice to have a sane language that doesn't take 5 years of expertise amongst all of the team members, before you can address what *shouldn't* be used

Swift, like rust provides all the pointer goodness if you want to use it. Also provides the ability to intermix C code without interfaces

Oh yeah, the Java is just as fast in real life thing... Please. Again read that article. While it is mostly about javascript, it all still applies to java.

A JIT is going to be a least 2x slower minimum no matter what for any nontrivial... there is no magic to get around that. Then throw on GC, that will slow it down another 50% or so. Then put it on a mobile platform that is already 10x slower... Of course Java can never be a systems language, there aren't pointers or anything similar. It isn't the way forward, that is for certain.

Here is what you are missing:

LLVM is enabling new languages that blur the lines between JIT and compiled. LLVM can do either. Right now Xcode JIT compiles code as you type in C/C++/objC. It is also used in openCL as a runtime JIT to compile C code to the target runtime platform (CPU or GPU). Now with Swift they have leveraged that ability further to JIT in a hot-coding environment... which is really the main advantage of interpreted and JITed languages: coding efficiency.

If you don't understand why GC is a bad idea better left in the 90s, read this: http://sealedabstract.com/rant...

There is reason Apple depreciated GC in objC for reference counting! The main jist is this: to get reasonable performance out of a GC system (meaning still 25-50% slower than manual memory management, you will need 6-to-10 times the RAM of say a C program. While this isn't a big deal on a desktop running a trivial application, this is a very expensive tradeoff in a mobile application. Lattner anticipated this problem many years ago when Apple was getting into mobile devices, and developed ARC for the compiler front end to provide a better solution, that is much more light weight.

LLVM was originally developed by Chris Lattner , Apples VC of Dev Tools. He joined Apple right after he developed the first version. And He and Apple have kept on driving and developing the project. You'll notice that the top 10 devs on the project are full time Apple employees. It would be hard to say LLVM is anything but a Apple project, under Apple's primary control

Fundamentally the interpreted/runtime nature of C# and python put them at a serious performance disadvantage, and well as generally limit what you can do with them. They can't be systems languages, they aren't even fully general purpose languages. The C# only allows for it to be suited for certain applications, as an application language. Python isn't high performance enough to be more than a scripting or prototyping language.

While Swift will be evangelized by only Apple initially, I hope it gets general traction. The other open source projects to come out of the Apple compiler group are probably the most important pieces of compiler tech in the last 10 years, including LLVM, Clang, OpenCL and libdispatch.

Nobody said Java was useless. I just can't think of why I'd use it over another language unless I had to. I'd either pick C/C++/objC for speed, or I'd pick Ruby/Python for efficiency, or I'd pick Groovy or Haskell if I was leaning functional... depending on my needs. I can't think of why I'd go in the middle. Seems like the worst of all worlds.

Rust and Swift are very on par languages attempts, with the exception that Swift also has a very nice compile time JIT and hot-coding environment. However, and this is crucial: Swift is beating Rust to the punch - and that is an important factor in languages. Swift had 200,000 devs download the language spec in the 1st 24 hours. That is probably 10x more than have ever downloaded the Rust spec.

Rust is still listed as experimental, as Swift is being rolled out to developers. The Rust team is still arguing over implementation, in an unfortunate design-by-committe kind of way. Rust has no killer-application driving it. Swift does. Swift is Driven by Chris Lattner, who has probably done more for the compiler world in the last 10 years than the next 25 guys put together (LLVM, Clang, OpenCL, etc). And Swift is backed by a huge amount of Apple dollars. Even the Original developer behind Rust has tipped his hat to the project. So Yeah, I expect Swift to rocket to the Top 5 languages in the next 2 years while Rust stays a academic plaything for many years to come.

Anyone who says 'X' language is crap, can safely be ignored.

Unlike our previous poster, though My opinion is that Java, is actually one of the least useful languages out there. It doesn't provide a higher level syntax than objC or C++, like the "better languages" Ruby, Python, etc. Nor does it provide the performance or memory footprint of systems languages like C, C++ or objC. It is bound by a runtime, that is meant to make it run-anywhere. Yet ironically the universal crown is going to javascript+HTML5, not java. Java in many ways is the new pascal, it is largely an educational language with a strong base in corporate intra-net applications.

You can use c, objC & C++ for decades to come. However Swift is very exciting (and I'm a embedded guy). It is the first serious language to come along that can challenge the C family of systems languages that I can remember. It has all of the native performance of C, the memory footprint advantages of reference counting, all of the syntactical goodness of ruby or python, the inherent parallelism of groovy and haskell, yet can morph into a JIT language in development with a very enticing hot-coding environment. With Chris Lattner & Apple backing it, it will be successful. I can't wait till it filters down to the open source space so I can use it in embedded systems.