Manycore Tsunami: You cannot develop software for manycore using today’s mainstream concurrency models. I know I sound like a broken record on this, but too many people have stuck their heads in the sand and are willfully ignoring an enormous problem. Writing manycore programs is going to be the hardest technical challenge in your career: harder than understanding object-oriented or functional programming, harder than browser incompatibilities, harder than tracking down memory leaks in a C program.

Declarative Tier-Splitting: From the mind that brought you LINQ comes declarative tier-splitting, in which you write all your code for a Web application in a single location and use attributes to let the compiler know “this needs to run in the browser, that needs to run on the server.” Erik Meijer’s Volta, Microsoft’s first foray into declarative tier-splitting, has gone dark, but the concept is being kicked around by some open-source developers, and I strongly suspect that Volta is being reworked and evolved rather than being abandoned.

You can never make the network invisible, but we have to move beyond the current nonsense in which one language and library must be mastered to manipulate and validate the view, and another language and library must be used on the server-side, often re-implementing the exact same validation work (since, of course, one can never trust client-side input). Even if JavaScript becomes a major server-side language, declarative tier-splitting would allow for better duplication, cleaner code and easier development.

JavaScript Becomes C: JavaScript will become more than an order of magnitude faster, will drive many applications, and will even gain strength as a viable server-side language. That’s the easy prediction; JavaScript performance is a major battleground in the re-emerged browser wars.

While JavaScript is not a language that inspires rapturous love, it’s serviceable enough. It lacks a concurrency model, but at least it doesn’t have a broken one. And its variable scoping rules are not to my taste, but the new “strict mode” of the recently published ECMAScript 5 spec will help.

Most importantly, JavaScript is the only language that can be counted upon in any browser, now and as far into the future as anyone can predict. In these ways, the language that JavaScript most resembles is C. There are, and will continue to be, tens of thousands of developers working in C (with hundreds of different compilers, by the way). I’ve long said that learning C is the single smartest thing you can do for your programming resume; from now on, mastery of JavaScript will be equally foundational.

Multicore Smartphones with Managed Runtimes: If you think this is a trivial prediction, consider that right now the iPhone 3GS is actually deliberately underclocked to preserve battery life (the 3GS runs an 833MHz-rated Samsung S5PC100 at 600MHz). I do not anticipate a breakthrough in battery technology, and people are only going to expect to push more and more media pixels through their phones (hey, is it too late to coin the term “vexting” for transmitting short videos?). Yet pockets are only so big. I’m not a hardware guy, so I won’t Moore’s Law this and Amdahl’s Law that. Instead, I’ll just say that I expect consumer demand to trump hardware difficulty.

As to the “managed” aspect, there’s no going back from the iPhone’s App Store: Mobile development is only going to become more and more important for developers. “Available on a smartphone” is a low-priority wishlist item for most business applications today, but it won’t remain low-priority for long.