Slashdot Mirror

Stop saying stupid things.

Right back atcha.

what the difference is between parallelism and concurrency.

Maybe you should read the Getting Started in Erlang guide. Sections 3.1 to 3.3 deal with concurrency; 3.4 deals with one off the many forms of parallelism. But, of course, you already knew that, right? Your claim to Erlang wasn't just BS, right?

I was more attracted by its stability.

Sure you were, sweetheart. Robustness is the chapter after Concurrency in the Getting Started guide. You know why? Because concurrency and parallelism is how Erlang achieves robustness.

We have solutions to reduce this sort of problem (at least once you get past the learning curve), but the top programming languages tend to implement very few of them. Reasoning about state is difficult, particularly when that state can be altered in unexpected ways. It is difficult to be confident that your code does what you think it does when you don't have a computer-checked method of specifying your intentions separate from what your code does.

There are no magic solutions here, at the least you will end up needing to spend more time writing in a specification language and that requires learning how it works. I would say that a gentle introduction to something like this is Elm which has an aim of stripping down typed functional programming into something that doesn't really need a C.S. degree. Here is a video which helps to explain what a better type system can do for your code. If you want to see something a bit more mind-bending check out Idris which has a much more powerful specification language which can prevent things like off-by-one errors or unbounded recursion in many cases. Moving off the scale of usability a bit, there is ATS which is a difficult language, but its specification language is able to make pointer arithmetic safe and doesn't bind you to immutable data structures. Hell, even Rust is full of good ideas that help to avoid these issues. And if fault-tolerant distributed systems are your thing, you need to check out Erlang (or its sibling Elixir) as there are so many great ideas that have been around for decades yet don't get nearly enough exposure.

This doesn't prevent us all from occasionally falling into this trap, but the themes of the languages listed is to find ways to encourage (or force) you to get the little things right the first time with computer-verified specification and to isolate the search space where problems are likely to occur.

Regardless of which language you use you'd end up with C or Assembly in the bottom.

I'm not sure if Rust is the way to go or if some different language is better. VMS/OpenVMS is using a large chunk of BLISS.

Another alternative I'd think of is Erlang. Or Prolog.

For the future - think outside the box. And that may not mean C, C++ or any of the traditional procedural languages.

9x9s uptime! Avoid creating broken software with the normal programming languages that cause years of software maintenance woes!

You don't know much about functional programming, first of all it is not what you think, your functions here like sin() have nothing to do with it.

Secondly, real world functional languages allow to modify state via monads. https://en.wikipedia.org/wiki/...

In a functional language "functions are first class citizens", that means they behave like objects. e.g. the following code:

      a = sum(sqrt(3.7), sqrt(4.2)

Creates three function objects, one instance of sum and two of sqrt, then it evaluates the "expression tree"
Behaving like objects means, you can store them, pass them around as parameters, create new functions by combining existing ones.

Regarding your answers: FP is not a hype, it is ages old, most likely older than you.

All modern languages support features of FP (C++ with functor objects, and now with lambdas), and nearly all modern languages either have lambdas or closures.

Depending on project and Java Version I use lambdas every day. If you use the STL in C++ you can not help yourself doing FP (albeit a bit limited)

Most prominent is probably Erlang. They used to write all the router and switching software in Ericssons gear in Erlang. https://www.erlang.org/about

That FP is only limited used is because the modern implementations e.g. in Java are so watered down and only support a subset of usages (e.g. lambdas/closures and the Streams API: http://www.oracle.com/technetw... )

What does this mean for the Erlang programming language? According to Wikipedia's article about Erlang, "Erlang/OTP is supported and maintained by the OTP product unit at Ericsson.".

Functional Languages are really cool in theory. However I find that for Real World development. Your code is often too tight for proper maintenance. Where Procedural and OOP is much better at fixing issues.

That's not the experience we had at Ericsson.

I can't help but think that you haven't really been involved in designing, building, fielding, and maintaining large systems based on FP. I have. With Erlang in particular we saw a four to ten fold increase in productivity.

And "too dense to fix" didn't even show up on the radar as a problem. Not by a long shot. Quite the opposite in fact, not having to wade through page after page of boiler plate (that could still trip you up, mind you) does wonders for focusing the mind on what the real problem actually was. As a colleague of mine was fond of putting it "After a day with Erlang I feel like I've solved business/domain problems, rather than 'doing programming'.

And good/competent, to half decent programmers could be retrained in a matter of days. The ones that couldn't, we didn't want anyway. And you shouldn't either.

IRL Erlang FTW :)

Erlang 2.0, was that before or after 1990? Erlang 18.2 was released today.

While Go and Swift are interesting incremental improvements, they are not taking into account what we learned about programming languages. In many ways, these two languages seem firmly stuck in the 1980s. For example, Go has no generics, and as far as I can tell, Swift still does not have the kind of true generic types I introduced in XL in 2000, i.e. the possibility to call "ordered" all types that have a less than, and then define functions with "ordered" instead of having to use <T> all over the place just like in C++ (and please, could we stop using angle brackets?)

More generally, there was a lot to be learned from more dynamic languages deriving from Lisp. Being able to treat code as data (homoiconicity) completely changes things. It means your language can be extended in itself, just like Lisp integrated object-oriented capabilities effortlessly. It means you can do metaprogramming, introspection, reflection, dynamic code generation, in a natural way rather than with specialised ad-hoc features. All things that Go or Swift spectacularly fail to do.

A real language redesign does not bring you incremental benefits, it should bring orders of magnitude on many tasks. I speak from experience. In XL, I can do complex arithmetic in 11 lines of code. What about Swift or Go? Ask yourself why Go can't offer complex arithmetic as a library package? Similarly, in Tao3D, I can do things HTML5 just can't, in a much less verbose, much higher-level language, and simple animations take 30 times less code than in JavaScript. The 30x factor tells me that I invented something new. Many others can demonstrate similar innovation.

I fail to see benefits of a similar order of magnitude with Swift or Go, and it annoys me. Companies like Apple and Google have the means, if only the financial ones, to make bigger things happen, in particular when smaller teams like ours already did a lot of investigative work.

As someone who has around 16 years of experience in life, I saw that learning Erlang helped me become a better SPARQL person, even though the two don't share much. If I hired someone, I would care more about the thought process [s]he uses to solve problems.

You are familiar with tuples, right?

That's the philosophy of erlang, "Let it crash". Apparently this leads to some of the most reliable systems. http://www.erlang.org/download/armstrong_thesis_2003.pdf
Apparently OP didn't heard about it, because this is the third way.

But really, Erlang is one of the better functional languages, as they go. It may be tough to learn, but it has enough software written in it to prove its wirth.

It has a "killer feature" that other functional languages lack; distributed nodes.... a clustering capability built into the language.

Key example: Try converting an array manipulation algorithm to efficient Erlang. It flat out can't be done: Erlang has no good syntax for indexed access of it's lists, forcing you to do a tail-recursive iteration counting through the list elements to get to the one you want. (This fundamental flaw killed the last project I worked on, so it's a pet peeve of an example.)

I have no Erlang experience, but I have experience in other functional languages. A quick Google suggests you should probably have used the 'array' module: http://www.erlang.org/doc/man/array.html

It doesn't matter what language you're using, you can't make a linked list (for that is what an Erlang list is) have the same performance characteristics as an array. It's not a fundamental flaw. You just refused to adopt the language's core paradigm.

Not in Erlang, it doesn't depend much on the OS as the Erlang "process" (think of it as an actor or lightweight process) is handled in user space by the runtime. On uniprocessor systems Erlang used to use a single OS thread. Now on SMP systems it uses at least as many threads as cores of course. The runtime also handles all I/Os in a non blocking way (poll / select or equivalent).

The goal here is to have a much lighter implementation for a concurrency context than what even an OS thread can provide. As a result creating / destroying Erlang processes is more efficient than OS threads, and the footprint of an Erlang process is much lower than a kernel thread (a page at the minimum for a thread). This allows better scaling in the amount of concurrent contexts than if directly using OS level threads, while providing the isolation of an OS process thanks to the language semantics.

More information in the Erlang doc and wikipedia page.

Apples and oranges. A telecom router will be running a specialised OS which is probably tightly intergrated with erlang. You won't be getting that sort of threading out of erlang on an x86 running windows or linux. If you put C on that router you'd probably get the same performance.

Nope, it's Linux. The mapping/slicing of Erlang thread to OS thread is indeed done by the Erlang runtime. And you most definately will get that amount of threading. Otherwise you wouldn't be using your cell phone.

Plenty of intelligent systems are written C/C++ - eg high speed trading. Sounds to me like you've spent too long in an ivory tower.

Didn't say they hadn't. Said that they weren't the best tool for the task. (Given a certain set of requirement of course.) I am saying that using a tool (Erlang) that was developed to build these kinds of large scale multiply redundant systems given the very considerable experience of how to build such systems is most probably the right tool.

And I don't get the "Ivory tower". That's usually reserved for academia. Erlang is industry, through and through. Started there and stayed there. And I have experience of all the tools you mention. I've worked as both a C/C++ programmer and an Erlang one. You obviously don't know much about Erlang.

Again. You need to read; e.g. Joe Armstrong's thesis , or his blog or something. (Don't worry, he's not an "academic" he got his thesis years *after* having developed Erlang.

And speaking of phones, the software that runs the phone network is largely written in C.

Well, in the US.

Ericson stuff will be written in Erlang.

Or go the other way - toward Church instead of Turing - check out Erlang or Haskell or Ocaml. In fact I recommend learning at least one of the above (I personally like Erlang, but that's just me) just to get a different perspective on computation than any of the 'classic' imperative, memory-location-oriented languages.

But it'll be hard to beat Qt's threading interface.

I don't know much about Qt's threading, but does it offer anything dramatically different than locks and mutexes?

I'll take a look into Erlang...

Qt does have support for locks and mutexes, and you could certainly use them in the traditional manner. However, it is very easy to write full programs with multiple threads without using a single lock or mutex in Qt and be perfectly safe in doing so if you use an QThread with Qt's Event Loop and Signal/Slot architecture. The whole program becomes very asynchronous as a result, but you never need a lock yourself - Qt's underlying functionality provides all the thread protections you need.

Now some of that is dependent on how you want to use the objects, and requires a big mental shift in programming methodologies. But I'd guess it's probably the same effect that Erlang has - at least from what I can tell from the documentation.

And I would probably select Erlang as programming language for a massive amount of cores.

Erlang is probably a good start.

http://en.wikipedia.org/wiki/Erlang_(programming_language)#Concurrency_and_distribution_orientation

Concurrency supports the primary method of error-handling in Erlang. When a process crashes, it neatly exits and sends a message to the controlling process which can take action. This way of error handling increases maintainability and reduces complexity of code

From the official source:

http://www.erlang.org/doc/reference_manual/processes.html#errors

Erlang has a built-in feature for error handling between processes. Terminating processes will emit exit signals to all linked processes, which may terminate as well or handle the exit in some way. This feature can be used to build hierarchical program structures where some processes are supervising other processes, for example restarting them if they terminate abnormally.

Asked to 'refer to OTP Design Principles for more information about OTP supervision trees, which use[s] this feature' I read this:

http://www.erlang.org/doc/design_principles/des_princ.html

A basic concept in Erlang/OTP is the supervision tree. This is a process structuring model based on the idea of workers and supervisors. Workers are processes which perform computations, that is, they do the actual work. Supervisors are processes which monitor the behaviour of workers. A supervisor can restart a worker if something goes wrong. The supervision tree is a hierarchical arrangement of code into supervisors and workers, making it possible to design and program fault-tolerant software.

This seems well fit? Create a real, physical machine for a language both able to reap its benefits and cope with the trade-off.
Or maybe I'm too far off (I'm bored technologically, allow me some paradigmatic change at slashdot).

TamedStochastics - Hiring.

Yes, checksumming on dedicated hardware was my first thought as well.

http://en.wikipedia.org/wiki/Erlang_(programming_language)#Concurrency_and_distribution_orientation

Concurrency supports the primary method of error-handling in Erlang. When a process crashes, it neatly exits and sends a message to the controlling process which can take action. This way of error handling increases maintainability and reduces complexity of code

From the official source:

http://www.erlang.org/doc/reference_manual/processes.html#errors

Erlang has a built-in feature for error handling between processes. Terminating processes will emit exit signals to all linked processes, which may terminate as well or handle the exit in some way. This feature can be used to build hierarchical program structures where some processes are supervising other processes, for example restarting them if they terminate abnormally.

Asked to 'refer to OTP Design Principles for more information about OTP supervision trees, which use[s] this feature' I read this:

http://www.erlang.org/doc/design_principles/des_princ.html

A basic concept in Erlang/OTP is the supervision tree. This is a process structuring model based on the idea of workers and supervisors. Workers are processes which perform computations, that is, they do the actual work. Supervisors are processes which monitor the behaviour of workers. A supervisor can restart a worker if something goes wrong. The supervision tree is a hierarchical arrangement of code into supervisors and workers, making it possible to design and program fault-tolerant software.

This seems well fit? Create a real, physical machine for a language both able to reap its benefits and cope with the trade-off.
Or maybe I'm too far off (I'm bored technologically, allow me some paradigmatic change at slashdot).

TamedStochastics - Hiring.

Yes, checksumming on dedicated hardware was my first thought as well.

These new interpreted GCd languages always claim to be ultra lightweight.

In this case an Erlang process needs 1232 bytes (more if you want HiPE and/or SMP support, which you probably do)

http://www3.erlang.org/doc/efficiency_guide/processes.html

That gives you 5GB of space just for the process structures it you want 5 million of them. A quick Google shows that lots of people have problems with Erlang running out of memory because they've screwed up the GC somehow, so this is definitely a minimum. Once those process start to allocate memory things will get much worse. Even the minimum, 5GB is not really good. What will it do to access locality for example?

Basically saying "lightweight compared to Unix and and Windows" isn't that impressive because both of those OSs are extremely bloated compared by the standards of embedded systems. Java, which Erlang claims to be faster than, is horrible for performance too.

Hokey interpreted languages are no match for native code written by someone who understands how processors execute it if you want lightweight.

Erlang is an older established language designed for parallel processing.

Erlang was first developed in 1986, making it about a decade older than Java or Ruby. It is younger than Perl or C, and just a tad older than Python. It is a mature language with a large support community, especially in industrial applications. It is time tested and proven.

It is also Open source and offers many options for commercial support.

Before anyone at DARPA thinks that they can design a better language for concurrent parallel programming then I think they should be forced to spend 1 year learning Ada, and a second year working in Ada. If they survive they will most likely be cured of the thought that the Defense department can design good programming languages

It sounds like these worms would be so much more elegantly architected using erlang. When will the worm industry finally escape its Windows/x86 ASM legacy and enter the wonderful world of distributed, functional dynamic programming?

However I am looking for a good book on programming threads from an applied point of view. I am looking for one or more texts that provide thorough coverage and provide meaningful exercises. Anyone have any ideas?

I went through grad school not too long ago for Computer Science (disclaimer: it was the kind of computer science degree that doesn't focus on hardware so I might not be the best expert on this). Anyway there were two books for the class.

One dealt with coding regular old C on a plain jain Unix machine and method of (I believe there are others) doing multithreaded in that environment is PThreads (or the super short overview). The book we used is the Addison Wesley book (ISBN 0-201-63392-2). It was informative and comprehensive ... wasn't concentrated specifically on applications like you ask but very good reference. Also, I think there are a lot of good books free online in respect to that topic.

As for Java, there was an O'Reilly book (there's probably a new version out for Java 6) that was pretty good. Not as great of a reference but better on applications of threads in Java. Although, as far as introductory material, I personally learned it all from java.sun.com. Although I can't vouch for whether this is an applied approach or not, I would suggest the concurrency tutorial and a good book on Java Patterns or even a design pattern wiki.

I've never done concurrent programming in C# or Python so I do not know first hand what is best. I do know that erlang has been fun to mess around with in my spare time though!

Recently I have been incorporating them more in my solutions for clients.

Most important rule of thumb of multi-threaded programming is to avoid it if possible. Maybe hardware (multi-core) will change that, maybe you feel the scheduler can't do its job as well as you can and maybe you feel it's more intuitive. But, often is the case, that you're just adding more complexity to your code resulting in more difficult bugs and harder maintenance for others. Keep it simple.

Twitter made a big mistake by basing their technology around Ruby on Rails.

Ruby on Rails is, of course, great for CRUD-style websites. It makes development lighting fast, and easy as sin. Twitter doesn't exactly fall into that category. Although Ruby on Rails is flexible enough to develop a small-scale version of the Twitter application, it just isn't capable of scaling.

They really need to be looking into Erlang. Erlang is perfect for the type of software they need to provide the service they offer (see ejabberd for example). Plus it's open source, and it has a vibrant online community, and frequent releases, numerous conferences, interfacing with other languages, and other goodies.

Erlang originated from, and has been successfully used within, the telecom industry, which is very similar to the market Twitter is involved with. Thus they should learn from the masters, and use Erlang wherever possible for their core services.

Twitter made a big mistake by basing their technology around Ruby on Rails.

Ruby on Rails is, of course, great for CRUD-style websites. It makes development lighting fast, and easy as sin. Twitter doesn't exactly fall into that category. Although Ruby on Rails is flexible enough to develop a small-scale version of the Twitter application, it just isn't capable of scaling.

They really need to be looking into Erlang. Erlang is perfect for the type of software they need to provide the service they offer (see ejabberd for example). Plus it's open source, and it has a vibrant online community, and frequent releases, numerous conferences, interfacing with other languages, and other goodies.

Erlang originated from, and has been successfully used within, the telecom industry, which is very similar to the market Twitter is involved with. Thus they should learn from the masters, and use Erlang wherever possible for their core services.

Twitter made a big mistake by basing their technology around Ruby on Rails.

Ruby on Rails is, of course, great for CRUD-style websites. It makes development lighting fast, and easy as sin. Twitter doesn't exactly fall into that category. Although Ruby on Rails is flexible enough to develop a small-scale version of the Twitter application, it just isn't capable of scaling.

They really need to be looking into Erlang. Erlang is perfect for the type of software they need to provide the service they offer (see ejabberd for example). Plus it's open source, and it has a vibrant online community, and frequent releases, numerous conferences, interfacing with other languages, and other goodies.

Erlang originated from, and has been successfully used within, the telecom industry, which is very similar to the market Twitter is involved with. Thus they should learn from the masters, and use Erlang wherever possible for their core services.

Erlang documentation has been improving over the last few releases. The Erlang core and OTP libraries are documented here. -- e

but no programming languages or tools to take advantage of them.

You expect that to come in the CPU box? Good tools exist, but you will have to learn how to use them.

finally figure out a way to program them that's practical.

You haven't heard of Erlang yet?

I think you misunderstand Erlang if you try to write audio drivers in it. :) You don't write drivers using Erlang, you write ports (probably in C) which takes care of all low-level hardware details. Ports are then connected to Erlang similar to how extension modules work in other scripting languages, with the difference that Erlang's ports are real processes that use IPC to communicate.

Erlangs strength is modelling interactions between components and taking advantage of asynchronous processing. For example, you wouldn't write a 3d engine using Erlang. But you could definitely use Erlang to control all player connections, NPC characters and other objects in your grand MMORPG.

There is a language that makes programming in threads much easier. See erlang.org.

Because really, multithreading doesn't have to be hard

Just a note -- Ericsson developed the Erlang language with telecom-style reliability in mind, and using it they have brought to market products like ATM switches with 99.9999999% uptime (that's nine nines, under 40ms of downtime per year). Telecom isn't just C's domain anymore.

That's why the really interesting work is being done in how to do multithreading without mutexes, semaphores, and all the other lock-based concurrency systems, which I'm surprised to see few people talking about in my skimming so far. Possibly because the old bucks aren't aware of these things, think they aren't fundamentally different, or possibly think they've been tried already.

The two most promising approaches I know of are message-passing based concurrency and Software Transactional Memory.

Message-passing based concurrency has been tried before, but to really reap the benefits it needs to be pervasive and easy. The current market leader in the field of message-based concurrency that gets things done in the real world (not just on paper) is Erlang. (I program professionally in Erlang.) I characterize it this way: Erlang doesn't make the issues of concurrency like deadlock go away, but it takes them from requiring superhuman intelligence to human intelligence.

As I like to say, a large enough quantitative change becomes a qualitative change. Yes, you can do everything in C that you do in Erlang, though you've got a lot of implementation in front of you and the resulting syntax will be awful. But by making the Right Thing easier in Erlang than the Wrong Thing, the experience is qualitatively different.

Software Transactional Memory is still in flux; the Haskell implementation has some relatively unique characteristics, but I have not yet decided how I feel about it. Erlang actually has an embryonic STM system called "Mnesia", which isn't quite the same as the hyper-pure on Haskell has, but on the other hand, we know it works. But it's something to keep an eye on; I'm experimenting with it in a personal project right now.

There are several promising lines of attack on the multicore problem, but none of them look like "semaphores and mutexes". Consensus seems to have developed that those are fundamentally flawed primitives to build software on. (Of course, message-passing is implemented with some locking, and STM can use things like that to be implemented, but saying that we are therefore building our systems on locks anyhow is exactly like claiming that since everything ends up as machine code, we should just program in machine code instead.)

If you thought your answer had merit, you could have linked us directly to the COSA project, instead of to a 5-page pointless review of all life as we know it.

And then we could have replied with a quick link to Erlang which has handled 10^5-process fine-grain concurrency in industrial PTT exchanges for a decade very easily, and much time would have been saved.

Ruby and Erlang are the two I've spent the most time with so far. I like Ruby enough so far, that I've decided to write the initial
batch of install scripts for OpenQabal in Ruby.

Outside of that wish-list, I also harbor some vague hope of one day finding time to dabble with Forth, Fortran, Perl, and maybe Dylan.

Then I noticed that you can't produce an executable file, although it's compiled: it has to run within its environment application. Big no-no.

There's a reason for that. Erlang is designed for writing robust meshes of tightly interacting processes, and supports things such as on-the-fly code upgrades (0 down time!). That doesn't mesh well with the idea of producing an "executable" file. But, when you come to think about it, what does these days? C might be your best answer, but even there you're more likely to end up with a slew of files that need to be installed for any but the most trivial applications.

Then it's excruciatingly slow.

I have that problem for the first day or so any time I switch paradigms. Functional programing is different in a lot of subtle ways, and things that would have been the obvious best way to approach a problem in Ruby (to choose another language I like a lot) simply aren't a good idea in erlang. And visa versa. Using runtime reflection to modify classes on the fly can do amazing things in Ruby, but it's a borderline nonsensical trick to try in erlang. Conversely, launching a bazillion threads diving down tail-recursive rabbit holes would quickly bring Ruby to it's knees, and often works great in erlang.

Then it has virtually no useful libraries.

It has more than you might realize in part because they tend to be called "applications" instead of libraries (probably as a consequence of the "everything is a service" philosophy). You don't think so much in terms of calling a library as requesting a service which is provided by an application.

In other words I couldn't figure out what to do with it

So here's an interesting idea to try, in case you're interested in giving it another shot: how about a highly parallel spam filter? Something that runs on a mail server, vets messages as they come it, and has the following properties:

• Messages that take a long time to scan don't hold up messages that arrive later but can be decided quickly.
• All the test suites proceed in parallel, and as soon as a determination can be made one way or another (spam/ham) the unfinished tests are abandoned.
• New tests / test suites can be added without taking the scanner down for even a fraction of a second, and existing tests can be updated or removed the same way.

Try it in erlang, and then try it in java or something, and I think you'll start to see the value of languages like erlang.

--MarkusQ

Most functionnal programming languages are a good step in this direction. Either Erlang with a message base approach or the pure way of (most interesting in my opinion) Haskell are very easy to run concurrently. Pure languages avoids mutable elements (think variables) so only the sequencing issue remains. That can be done with special instructions (seq) or by the language itseft (there is many Haskell variants going this way).

Singularity also introduces a software-isolated process (SIP) mechanism, which makes it possible for lightweight processes to coexist safely with their own sealed code environments in the same memory space. All communication between SIPs is conducted through channels. The use of SIPs effectively eliminates the overhead traditionally incurred by context-switching in conventional microkernels.

Replying to self; "yes Dorothy, Erlang does support SMP these days".

There's a reason Google's moving to Erlang so fast - they're discovering that a lot of the tools they've half-assed reinvented in Python already exist in Erlang in far more flexible fashions. This is nothing more than another map/reduce fiasco - a first generation solution to a problem that the internet adores because it's never seen any solution to the problem, but something which has been far better addressed in real industry for thirty or so years. If google would just quit stealing people from Microsoft, who makes application and system software, and start stealing people from AT&T and Ericsson, who make hard realtime system software, they'd find they wouldn't have to spend so much time poorly re-walking what's already been pathed

Profound ignorance! Google is evaluating ejabberd/erlang for messaging services/framework. And you claim they're moving to Erlang!? Do you know what percentage of code of Google is written in python? Your criticism of map-reduce is so laughable, it's not worth arguing.

Mnesia can handle bigger datasets over more nodes in realtime, offers the user better control of which data is on which node, and has a much more flexible locational querying system. There's nothing you can do in Bigtable that you can't do in Mnesia, and the reverse is most certainly not true.

You have done such a spectacularly poor job of making your case that all I can imagine as your reason to say something like that is:

1. 1. You think mnesia doesn't have indices
2. 2. You think Mnesia is manually locked
3. 3. You think Mnesia isn't versionned
4. 4. You think Bigtable can handle more physical storage than Mnesia

Of those, not only are you wrong on every count, but only the last is in any way something that someone who knows even the basics about distributed databases would even begin to consider. Doesn't support indices? Are you nuts? You really think there's a database that can't sort its contents?

Unbelievable

Indeed, I was not even criticizing Mnesia, it's a fine distributed in-memory oriented db great for its purpose, but driving an imaginary technodrome while laughing at a real bullet train is one of the funniest things I've read so far on slashdot.

Oddly enough, I just watched a presentation about this very topic, with an emphasis on Erlang's model for concurrency. The slides are available here:

http://www.algorithm.com.au/downloads/talks/Concurrency-and-Erlang-LCA2007-andrep.pdf

The presentation itself (OGG Theora video available here) included an interesting quote from Tim Sweeney, creator of the Unreal Engine: "Shared state concurrency is hopelessly intractable."

The point expounded upon in the presentation is that when you have thousands of mutable objects, say in a video game, that are updated many times per second, and each of which touches 5-10 other objects, manual synchronization is hopelessly useless. And if Tim Sweeney thinks it's an intractable problem, what hope is there for us mere mortals?

The rest of this presentation served as an introduction to the Erlang model of concurrency, wherein lightweight threads have no shared state between them. Rather, thread communication is performed by an asynchronous, nothing-shared message passing system. Erlang was created by Ericsson and has been used to create a variety of highly scalable industrial applications, as well as more familiar programs such as the ejabberd Jabber daemon.

This type of concurrency really looks to be the way forward to efficient utilization of multi-core systems, and I encourage everyone to at least play with Erlang a little to gain some perspective on this style of programming.

For a stylish introduction to the language from our Swedish friends, be sure to check out Erlang: The Movie.

Erlang's in-memory database system was originally called Amnesia. Someone at Ericsson didn't like the name so they dropped the "a" and Amnesia became Mnesia.

Erlang's in-memory database system was originally called Amnesia. Someone at Ericsson didn't like the name so they dropped the "a" and Amnesia became Mnesia.

As far as I can tell, you didn't learn literally the first thing about the language (atoms and Variables), couldn't figure out a single error message, and are still mad about it.

As someone who has been doing this for only a couple of months, I think you're doing yourself a disservice. Erlang is a really powerful language that is pretty dang easy to program in once you get the basics.

Regarding the documentation, the one thing you complain about is explained in the erlang manual. click on getting started, modules and functions. it's section 2.2.

I will admit that exception traces took me a while to get used to, but they do make sense after a while.