The future is threaded.

At the commodity hardware level, this is already the case thanks to Intel Hyperthreading, Intel, AMD (and others) dual core processors. AMP, SMP & NUMA. Dual, quad & 8-way motherboards. In the future it will be more so. Eg. The Cell processor. Quad-core technology from Intel and AMD coming in 2007.

At the software level, very little existing software makes use of threading. There are several reasons for this:

1. Software needs to be written from the ground up with threading in mind in order to properly benefit from it.
2. Retro-fitting threading to existing applications is rarely effective because threading exacerbates the effect of every bad programming practice.
   • Re-entrancy issues can not be glossed over. Whether in the application code, language runtime or OS.
   • Global data-structures become even more vulnerable.
   • Tight coupled code causes low granularity. Low granularity can make threading expensive.
   • Memory management becomes paramount.
     • Stop the world GC will have a disastrous effect upon performance.
     • Monolithic heap management will suck the life out of efficiency.
3. Existing code that can benefit from threading, often uses event driven and/or state machine techniques to approximate those benefits, but code designed to utilise those techniques is usually structured such that it does not lend itself to conversion to threading.
4. Existing code that already achieves parallelism through forking, that could also benefit from shared state, is often difficult to adapt to threading due to the assumptions that can be safely made when using forking that no longer hold true with threading.

Redeveloping existing, successful applications that could benefit from threading is often slow to happen. Again, for a variety of reasons:

1. Mid-life, ground-up, redesign of an existing application is always a major undertaking, even where there are clear benefits to doing so.
2. In many environments threading is seen as hard.
3. In many environments, there is a lack of both understanding and the skills required to implement threading well.

Even when developing new applications, that could obviously benefit from threading, it is overlooked, ignored or explicitly ruled out. Again there are a variety reasons why this happens, most of which are already covered above.

Much of the resistance/reluctance to utilise threading can be attributed to a single factor--there are few if any good tools available.

• Most languages--that the majority of people use--either do not support threading at all, or support it as an afterthought. And then only at the lowest level.
• There are few good abstractions of shared state. If every program still had to deal with disk-bound data by directly manipulating physical blocks and freespace chains, very few programs that manipulate file-based data would exist--that's most programs in existence. Today's ubiquitous hierarchical filesystems make it seem as if there was never any other way, and that tends to imply that they are perfect. But we also have RDBMSs, which are most definitely not hierarchical, and not file-based, (Although they often live on hierarchical filesystems.).
• Most of todays programming tools--compilers, interpreters, editors, debuggers, runtime libraries etc.--are the latest evolutions of the same tools that go back years., In many cases, decades.

And like any other type of existing application, adaption to threading is difficult, resisted ,expensive and risky. Redesign from the ground up with threading in mind, implies throwing away thousands or millions of development hours in thoroughly tried and tested tools and libraries.

Could that possibly be worth the trouble?

What if an existing, popular, powerful and flexible language was already being redesigned from the ground up.

If that language was already looking to support simple syntax and intuitive semantics for Distributed Operations?

    if( any( @list ) == constant ) ...
    @list1 >> += << @list2
[download]

And those DistOps inherently lent themselves to being run concurrently on multiple hyperthreads/cores/CPUs?

What if the entire tool-chain to support that new language was also already being redesigned from the ground up?

Doesn't it make sense to write those tools with threading not just "in mind", but as a high priority?

Will those tools be all they could be, if their architects "Don't do threads"? If the implementors "do not see the need for threads"?

Indeed, does it bode well for the future of those tools if the implementors do not use the languages that those tools are to support, And don't have the slightest feel for what will drive the needs and uses of those languages in the future?

Does the

• complete absence of a threads.pdd from the specification;
• that the term "threads" appears only 35 times in the entire documentation set;
• that the "failed" ithreads model, so widely denigrated and despised, is being nearly exactly replicated for the underpinnings of the new language;

inspire you with confidence?

What about userspace threading? Many languages provide this and many programmers find it's determinism and light weight lends itself to many things that they want to do. It's not a replacement for kernel threads, but if threads != interpreter, then providing primitives to allow cooperative, user threading to run within preemptive kernel threading becomes not just possible but almost trivial. Whether this is provided at the VM level or the language level. Trying to hack user space threading into a language when thread == interpeter becomes a completely different ballgame.