smedda: Have you heard of Mnesia? http://www.erlang.org/doc/apps/mnesia/index.html »

mdavis0452: in my reply to your comment above, note that the runtime does the work of multiplexing jobs to threads, rather than you. So replace "[y]ou" with "the runtime job scheduler." I'm not sure how Erlang's runtime does it, but plenty of other systems work this way: you put jobs on a work queue, and the runtime pulls off jobs from the queue and assigns them to processors. »

mdavis0452: think of "Erlang thread" as a job. You can multiplex N jobs onto M operating system threads in which N >= M. »

Uh, CUDA threads have nothing to do with Erlang threads, except for perhaps the name and the idea of parallelism. CUDA threads are basically an abstraction for what looks like an old-school vector processor like the Cray 1. If you think "I'm programming a much smaller, cheaper, lower-power version of the Cray 1," you'll probably write very efficient CUDA code. If you try to write a CUDA program with the idea of Erlang threads (message-passing with a message queue), you probably won't get very far. »

I didn't have much to say about your previous post because it's obvious that a good runtime that supports high-level language features is the right way to go about developing on multicore. However, one shouldn't confuse a good runtime with the language built on top of it. The latter is mostly syntax and for skilled programmers, syntax is just religion ;-) Furthermore, one can build many different languages on top of the same runtime, which also can enable interoperation of the different languages' data structures, and please the expert programmers who are particular about the syntax they use. The nonexpert programmers (who are primarily domain experts and not hackers) shouldn't have to care about the syntax -- they only want to "get things done" and are willing to endure any arcane and annoying syntax in order to have libraries that let them solve their problems with a minimum of coding time. (Perl, COBOL, APL, ...) Building a good runtime is hard and not as attractive for marketing as making a new language, hence it's not done very much. Often the groups that do make an investment in a runtime do it to solve internal problems (e.g., "How do we support the current ecosystem of multiple development languages, while sharing common system and debugging facilities?") which shouldn't be visible to ordinary programmers. However, the really interesting features for parallelism and concurrency (e.g., load balancing, parallel garbage collection, reliability, debug traces, software transactional memory) are all in the runtime. »