informationweek.com
I'll make a bold prediction: if they don't open-source it, it'll be effectively stillborn.
I have to admit, I'm not particularly impressed with what I've seen of Ct so far. As far as I can tell, they've essentially introduced some SIMD-esque data structures that have multithreaded operations. This looks passable for numerical code, but limited to one machine. Maybe they can make a compiler smart enough to spread the load over a cluster, but I'm not holding my breath. The people I've met who do this kind of numerical stuff would never trust a compiler to do the parallelisation for them anyway.
For the 95%+ of software out there that's not bottlenecked on vector/matrix processing, this doesn't look promising. Besides, who is going to switch back to a C/C++-like language that can't be compiled with existing tools and will require some porting?
Obviously written by a non-coder; because 5% new/changed keywords is HUGE. And learning the keywords isn't the problem, it's knowing how and when to use them. Every modern (real) language has multi-threading support (albeit not as described in the article), just most people don't know how to use it.
At any rate, it uses a runtime environment. If I wanted multi-threaded code that uses a runtime environment, I'd turn to C# or Java, not Ct. What Intel should have focused on (in addition to the extension to the language's own library) is making pure compile-time changes to the language that enable such features, not mixed compile/run-time platforms.
Being able to program against multiple cores/processors/machines is one of the biggest "unsolved" problems facing us right now.
Intel could make itself a real brand boost by embracing external developers, especially if you plan on hacking C/C++.
It's not much of a problem if you use correctly use multithreading. See also: Erlang
As for Erlang, I'm pretty sure it wasn't meant for numerical calculations, and since it's interpreter, it can't really be used for all real-time apps. Although it's process model is novel, the implementation might not be perfect for everything right now. Correct me if I'm wrong on this (which I might well be, since I have not spent too much time writing Erlang code.)
I think what the parent meant is that writing multithreaded programs easily and quickly (not to mention bug-free) is hard, hard enough to be called a problem.