The question is why.

There are lots of really interesting and hard problems in CS. But very rarely do I interview a CS grad that has any experience in them, or more frustrating, doesn't even know the nomenclature (e.g. define "heuristics").

They can't even address simple on-the-spot software solutions (e.g. write a simple C function that flips the order of a link-list). All that time spent doing stuff in java has rotted their brains.

However, while this might be true for the work roles people are performing, the article at the end shows that EEs have lower unemployment than CSs.

This is my experience: When interviewing EEs and CS degreed employees, I'll chose the EE over CS 9 out of 10 times for a software job. In general they have a stronger grasp of the big picture, hardware, software & firmware. In fact I've been downright disappointed with the level of CS expertise by CS grads lately. It is as if the universities are training them for javascript, web site production, and IT support as apposed to a deep understanding of the CS field.

What we can say about this article is: there are more software than hardware jobs, but EEs are dual purpose, and overall have lower unemployment.

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.