Slashdot Mirror

No, people are suggesting that it is a good idea to update code in applications in real time without a complete redeployment, which should include storing modifications that are going to be applied to production within some sort of a source control system, then installing the entire code base that will be deployed in production to some testing / staging environment, then moving code to production.

I am saying that allowing deployments of a function or of a line of code to production needs to be done only in very special cases and controlled environments that have processes that allow for these kinds of modifications.

Well, that makes total sense. The thing is that the Erlang/OTP Release infrastructure doesn't easily allow piecemeal updates; it's designed to enable full deployments with no (or minimal) downtime. You might be interested in reading about release handling principles under OTP. I'm sure the system can be abused, but it's not the free-for-all that some people seem to think.

Or, maybe, the Erlang FAQ has a better answer:

10.1. Why is Erlang called "Erlang"?

Erlang is named after the mathematician Agner Erlang. Among other things, he worked on queueing theory. The original implementors also tend to avoid denying that Erlang sounds a little like "ERicsson LANGuage".

I am (well, was, at least) an Erlang Programmer. I was toying around with Erlang for some small projects with distributed programming.

I've been looking forward to Joe's book for a long time, as he's one of the few big names in the Erlang community, and has done a lot of work (both code and, even more importantly, documentation) for the community -- first that jumps to mind is his important look at Yaws vs. apache.

There are serious problems with the Erlang language as a whole and the community, right now. The mailing lists are actually pretty good, but quite frankly, the documentation online is terrible and the Erlang interpreter is pretty rudimentary. Not to mention basic problems with the syntax and grammar of the Erlang language itself. When I was learning Erlang a few months back, I was pretty frustrated that about the only source of documentation was on erlang.org, and they.. weren't great. For instance, there needs to be a big warning right at the beginning explaining that atomic values always start with a lowercase letter and all other variables must begin with a capital letter. This must be a huge problem for other beginners (at least, I hope I assume I wasn't alone..) compounded by the unfriendliness of the error messages produced by the Erlang interpreter.

Now that I've switched over to doing as much as I can in Python, which has a great user community, wonderful docs, a healthy standard library, and a reasonably helpful interpreter.. I don't really worry about Erlang that much anymore. It would be wonderful if I could write, say, web crawlers (I work in web security) in Erlang. But the mysql support in Erlang looks alpha-quality at best, and AFAIK there's nothing even remotely similar to Python's urllib2 for basic web client functionality in Erlang.

I think it says a lot that so much attention is paid to a language that is so rough around the edges, unfriendly, and lacking in documentation. Even given all that.. the ease of use of the concurrency and message passing in Erlang is so fantastic that it almost makes up for the rough spots.

On a final note, I'd like to point out to anyone interested that I think there's a huge void out there for a language that's as easy to use and learn as Python, but with the concurrency and message passing in Erlang. It actually might not take that much work to build a network-transparent message passing interface as a Python module (I've looked into Pyro a bit.. it looks rather cumbersome and makes easy things too hard, correct me if I'm wrong). Also, modern languages need basic support for splitting up the workloads of map() or similar trivially parallelizable functions across multiple processors/cores (I know the Perl6 group was thinking about this.. not sure if this works in Parrot now or what). Basically, modern languages like Python/Perl/Ruby should really think more about making simple modules to mimic the message passing that Erlang has. Really, a little bit of code could go a long way. The Google team put together sawzall which looks kind of cool, on this note..

What combinator did you find in the standard library? Anyhow, you are right, and I am aware of the fact that people should use these combinators. But it did happen that I had to use an additional function and recursion (instead of "for"). Maybe I didn't study the documetaion well enough - although one of my startpages in my browser is exactly http://www.erlang.org/doc/, and I have studied it some time.

Not to nit-pick (okay, well, only a little) this 300 bytes thing floating around is in error; the correct figure is 318 machine words, as seen at the erlang efficiency guide. Still a pittance, but quite a bit larger than 300 bytes on most architectures.

Erlang is indeed the perfect candidate for your issues. http://erlang.org/

Erlang's Wikipedia entry is longer than an elevator pitch, but has some decent information. Erlang's primary site is here.

Of course - since many today tend to do object oriented programming (for good and bad) the procedural programming may seem "fresh" for some.

And there are other programming areas that can be considered too;

• Concurrent Programming, E.g. Erlang.
• Logic Programming, E.g. Prolog.
• Functional programming, E.g. ML

We don't need newer methods for concurrency control. The actor model and CSP work just fine. CSP has been implemented in a handfull of languages, including Limbo. The actor model also has been implemented in a bunch of languages, including Erlang which has been used to build the massively concurrent British telecommunications system.

Concurrency is a problem that was solved decades ago.

There are many misunderstandings about parallelism, as it is evident from this discussion. Some posters said that "my O/S already runs in multicore/multicpu systems, thank you very much"...some others said that some tasks are like word processing is non-parallelizable etc.

The misunderstandings lie not in what parallelism is, but what Intel and other companies are trying to achieve. The quest for parallelism is not about running lots of programs in parallel, but extracting the parallelism out of sequentially written programs, including kernels. In order to improve performance, any parallelism that lies in our applications but is not exploited right now must be utilized, if we want to see real improvements in the future.

Modern CPUs do many tricks in order to increase parallelism, like pipelining and out-of-order execution. Current research at Intel has produced an 80-core CPU. It is highly unlikely that any of us will run 80 programs simultaneously tomorrow, so either this research is for servers only (highly unlikely because Intel will need to sell a lot of these chips to cover research expenses), or Intel knows that programs can be parallelized even more.

Compilers can not identify all possible parallel paths of execution, because it is an intractable problem. Writing complicated multithreaded programs using threads, semaphores and mutexes is quite difficult. So what is needed is another software architecture that allows programs to be easily parallelized.

Ericsson has dealt with these problems a lot time ago, and the result was Erlang. Based on the Actor model, Erlang programs can contain thousands of objects working in parallel, and the programmer need not worry about how to lock/unlock resources.

Microsoft's only option is to ditch C and use another language for their O/S. C can not work with the Actor model, unless modified. The best option for them is to make a C-like low-level language that includes the Actor model as part of the language specification. They can combine Cyclone, a version of C which is safe, with the best parts of ADA and Erlang, and come up with a language which allows the easiest possible path to writing parallelizable programs. And there is a big opportunity for them to put bounds checking and garbage collection to all their code, so as that two basic problems (buffer overflows and wild pointers) are solved at last.

The language you're describing has been around for a long time, under various names. I recommend you look into either erlang or mozart-oz.

So why not just limit access to C? Have e.g. p1 responsible for it, and let everyone else communicate with p1.

That's a great idea, and it's called shared-nothing concurrency. Check out languages like Erlang.

- Concurrent Sequential Programs - CSP. This is the programming model behind Erlang - one of the most successful concurrent programming languages available. Writing large, concurrent, robust apps is as simple as 'hello world' in Erlang. There is a whole new way of thinking that is pretty much mind bending. However, it is that new methodology that is key to the concurrency and robustness of the end applications. Be warned, it's functional!

Parallel programming doesn't have to be quite as painful as it currently is. The catch is that you have to face the fact that you can't go on thinking with a sequential paradigm and have some tool, library, or methodology magically make everything work. And now, I'm not talking about functional programming. Functional programming is great, and has a lot going for it, but solving concurrent programming issues is not one of those things. Functional programming deals with concurrency issues by simply avoiding them. For problems that have no state and can be coded purely functionally this is fine, but for a large number of problems you end up either tainting the purity of your functions, or wrapping things up in monads which end up having the same concurrency issues all over again. It does have the benefit that you can isolate the state, and code that doesn't need it is fine, but it doesn't solve the issue of concurrent programming.

No, the different sorts of paradigms I'm talking about no shared state, message passing concurrency models ala CSP and pi Calculus and the Actor Model. That sort of approach in terms of how to think about the problem shows up in languages like Erlang, and Oz which handle concurrency well. The aim here is to make message passing and threads lightweight and integrated right into the language. You think in terms actors passing data, and the language supports you in thinking this way. Personally I'm rather fond of SCOOP for Eiffel which elegantly integrates this idea into OO paradigms (an object making a method call is, ostensibly, passing a message after all). That's still research work though (only available as a preprocessor and library, with promises of eventually integrating it into the compiler). At least it makes thinking about concurrency easier, while still staying somewhat close more traditional paradigms (it's well worth having a look at if you've never heard of it).

The reality, however, is that these new languages which provide the newer and better paradigms for thinking and reasoning about concurrent code, just aren't going to get developer uptake. Programmers are too conservative and too wedded to their C, C++, and Java to step off and think as differently as the solution really requires. No, what I expect we'll get is kluginess retrofitted on to existing languages in a slipshod way that sort of work, in as much as it is an improvement over previous concurrent programming in that language, but doesn't really make the leap required to make the problem truly significantly easier.

Of course, security through obscurity is badbear.

That said, there are times - and this is one of them - that I'm glad my recently most common database isn't fundamentally SQL, or anything well-recognized. It also helps that (I believe) mnesia is immune to injection, given that its queries are never textual, but rather always functional, and given that data are always presented as arguments. Every route to injection I'm aware of just doesn't make sense in context (though if someone knows a way attack Mnesia, I'd love to hear about it.)

Sure, there are times at which SQL is a major win over mnemosyne, but they're not common. Sure, it's nice to have a database be ready for you at any host, instead of having to take the time to find a good host who lets you run stuff. But when it comes down to it, the atypical performance characteristics of Erlang (especially since I write multiplayer games, for which massive concurrency is win) and the ridiculous speed of Mnesia make me miss SQL less every day.

'Course, client stuff still needs to work on MySQL. :(

Each modern OS has a way to do graphics, fonts, widgets, etc. Why the Java group insists on shunning these in favor of kinda-sorta-look-alikes is beyond me. The code is there. Just call it. See Eclipse for an example of how to do this.

On a related note, if you want a profoundly cool, stable, robust, distributed, declarative language, how about http://www.erlang.org/?

Look, I don't think I'm asking something too unreasonable here.

By limiting to open source only, I think you are.

Let's take the classic example of a difficult multi-threading problem: a DBMS. It's not completely separable, like an FTP server, and it's not effectively serialised, like an X11 server.

Have people written highly-threaded DBMSes in functional languages? Sure. Are they open source? Probably not. There are a few decent open source DBMSes, so there's really no itch to scratch. (So why was Mnesia written? For telecommunications applications, like telephone exchanges; not exactly a haven for open source.)

And it is called boost::futures

The theory behind it, though, it not new: the Actor model is quite old, and it has been used in Erlang for quite sometime.

Concurrency is easy.

Besides this, is there a solution to this in the form of new programming languages?

Erlang and Limbo have concurrency primitives built-in. Both used CSP as a launching point. Both give the programming easy-to-use, lightweight processes and message passing. Processes share nothing.

However, neither have built-in support for multiple cores or multiple CPUs at the moment. It's just not a priority for the teams behind them. You can cheat such a setup with Erlang, however, as you can spawn processes on remote machines or remote Erlang instances. If you had two Erlang instances on the same machine, each would run on its own core, so all you'd need to do was spawn a process on each and then message pass between the two.

Unfortunately, Erlang is SLOW when doing anything EXCEPT concurrency. (At least when rated by http://shootout.alioth.debian.org/ ).

Actually, the Erlang FAQ specifically mentions that most larger projects use other languages for the computationally expensive sections.

My current idea for a hack is connection via TCP connections and pickled data.

You might want to look at this before you start. I'm not sure how well it'd work with Python, but it's something to consider.

Unfortunately, Erlang is SLOW when doing anything EXCEPT concurrency. (At least when rated by http://shootout.alioth.debian.org/ ).

Actually, the Erlang FAQ specifically mentions that most larger projects use other languages for the computationally expensive sections.

My current idea for a hack is connection via TCP connections and pickled data.

You might want to look at this before you start. I'm not sure how well it'd work with Python, but it's something to consider.

There are a lot of techniques available that can make software reuse possible. One of them is Test Driven Development. When every bit of your functionality is checked with automated tests you can easily put your sourcecode into another contexts, rerun all the tests, and if they are ok it is a good indicator that it will work.

We also need a paradigm shift to concurrent programming. This will IMHO inevitable happen, as the processors are becoming more and more multicore. The currently used threading model is totally infeasible, we need something like the Erlang model.

Erlang seems to be on the right track. The thesis Making Reliable Distributed Systems in the Presence of Software Errors should be a must read for everyone who cares about reliable software. We are going to have to live with the fact that software will never be error free.

Another concept for reliable software could be multi agent systems, that have similar ideas like in Erlang but go a far step forward.

All in all, reliable software and reliable software reuse definitely is possible. Just not with mainstream technology.

• Erlang - Do I really want to recode all my apps using tail recursive functions?
   
• lua - Love the language but there's breakage between versions and poorly maintained libs.
   
• Haxe - New, I don't do flash. I'm only interested in server side code.
   
• Pike - Much cleaner and faster than PHP.
  

Erlang already support multiple cores, it used to be that you had to start an erlang node for every core/cpu. Today a single erlang os-process will scale to the cores available.

But from the programming point of view, erlang has supported multiple cores for as long as it has existed.

In erlang when you send a message to another process, you don't know if that other process is executing within the same OS-process or is executing in another OS-process, or even running on an distant machine. That is very good, because you don't have to rewrite anything to support distribution.

Concurrency is one of many features where erlang makes things easier for you.

On the other hand.. if you look at java or perl, those green processes or real threads (pthread) is just slapped on, like any other library. The language doesn't have any support for processes/threads nor is it oriented around processes/threads. This doesn't exclude you from doing erlang like stuff. It is just that an 10 line erlang-hello will expand to an 100 line pthread beast with sharp mutexes slashing around.

References:

New smp feature in erlang:
http://www.erlang.org/doc/doc-5.5.1/doc/highlights .html

Look at chapter 3, you don't have to understand erlang to follow:
http://erlang.org/doc/doc-5.5/doc/getting_started/ part_frame.html

Erlang already support multiple cores, it used to be that you had to start an erlang node for every core/cpu. Today a single erlang os-process will scale to the cores available.

But from the programming point of view, erlang has supported multiple cores for as long as it has existed.

In erlang when you send a message to another process, you don't know if that other process is executing within the same OS-process or is executing in another OS-process, or even running on an distant machine. That is very good, because you don't have to rewrite anything to support distribution.

Concurrency is one of many features where erlang makes things easier for you.

On the other hand.. if you look at java or perl, those green processes or real threads (pthread) is just slapped on, like any other library. The language doesn't have any support for processes/threads nor is it oriented around processes/threads. This doesn't exclude you from doing erlang like stuff. It is just that an 10 line erlang-hello will expand to an 100 line pthread beast with sharp mutexes slashing around.

References:

New smp feature in erlang:
http://www.erlang.org/doc/doc-5.5.1/doc/highlights .html

Look at chapter 3, you don't have to understand erlang to follow:
http://erlang.org/doc/doc-5.5/doc/getting_started/ part_frame.html

That's why C is reaching its limit. Things like Erlang and Clean, as well as parallizing Lisp compilers will become more widely used to handle these multiprocessing systems.

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

Take a look at Erlang, it's an interpreted language from Ericsson and can support that sort of load. It's used mainly for soft real-time constrained, telco applications. There's an old video demonstration of the language available here.

Well, yeah, you could use Java I suppose. But it's still using a shared-state concurrency model, which is inherently complex no matter what you do. Instead of that, you could use Erlang, a functional language using message-passing concurrency, and make all that complexity go away. Ericsson uses it to run telephone switches. Someone else wrote a first-person shooter with it. It can handle thousands of lightweight threads at once, and does distributed apps transparently too. For an intro to Erlang from a Java guy's perspective, check out this article by Bruce Tate.

Realized that link wasn't as helpful as I remembered. But here are some other good general links that should get you going.

http://en.wikipedia.org/wiki/Concurrent_computing
http://en.wikipedia.org/wiki/Message_passing
http://en.wikipedia.org/wiki/Actor_model

The E lang has some good documentation on concurrency, even if you don't use it.
http://www.erights.org/elib/concurrency/

As does Erlang.
http://www.erlang.org/download/erlang-book-part1.p df

You're right! It would be better to get a technology designed for multi-threaded programming. But then you go on to push Java? I'm confused.

Now, granted, Java does provide builtin support for concurrency. Although that support is an implementation of the 30-year old monitor concurrency primitive, which even one of its principal inventors (Tony Hoare) long ago abandoned in favor of better things. Not to mention that Java's implementation of monitors is known to be broken (or at least was - maybe they've fixed it now?).

Doug Lea's util.concurrent package (now part of Java 1.5) certainly helps things on the Java front, but it's hardly a panacaea. Depending on the application, you may want to take a look at JCSP instead - it provides for an almost direct translation of ideas from Tony Hoare's CSP into Java. For languages with good concurrency support out of the box, you might try Erlang, Ada, Mozart/Oz, E, or Eiffel.

A bit off-topic? I found some recent readings about the future of processing technology, and developments in software to exploit this, to be quite interesting.

Man, I gotta go find out why multithreading is so hard. Gotta try and get back into it someday and have a play around, get to truly understand it. I've only played with "Intro to Threads" type programs in Java, so there should be plenty for me to learn, when I get there...

In the mean time, there's a lot of things to look at for someone lazy like me. If I'm not gonna do them, I can read about them first. My favourite starting points have got to be (many Lisp related): Bill Clementson's blog. Erlisp (because I don't know Erlang itself, so Lispy Erlang would be a good way to understand the concepts I feel). Short explanation here. There's Erlang itself, but don't forget all the others: MapReduce, Termite (quite simple & beautiful code) and cl-muproc (all on the second link above).

Once (is it if or when?) single processors riding on Moore's Law stop working, is there no escape from concurrent programming? Looks like Erlang (currently being "borged" into Lisp, yay) is where the action is gonna be if massively multithreaded architecture turns out to be the winner for parallel/concurrency/distributed computing.

aristus,
I started looking at erlang in Fall 2004. Its my first serious try at functional programing so I consider my a newbie in functional idioms. However, erlang is not purely functional and is accessible to people with OO experience.
I was a lurker on the erlang-questions maillist for 6 months before making a final decision to start building my apps with erlang. The maillist community is very solid and should be considered a base for your ongoing adoption of erlang.
Here is the maillist and faq link:
http://www.erlang.org/faq.html
If you download any erlang install http://www.erlang.org/download.html, lots of docs are included. There are also some docs not included:
http://www.erlang.org/doc.html
I consider this doc a must read for anyone starting erlang:
http://www.erlang.org/download/erlang-book-part1.p df
The http://www.trapexit.org/ site is a very good portal for docs and the forums are a bi-directional link to the erlang-questions maillist.
The howtos are good to start with:
http://www.trapexit.org/docs/howto/
If you will develop anything requiring a web server, go directly to http://yaws.hyber.org./ Mostly good docs here. Yaws is the most excellent web server written in erlang.
jungerl is a repository of mostly small erlang libraries. Lots of good tools and example code in here:
http://jungerl.sourceforge.net/
ejabberd http://ejabberd.jabber.ru/, a jabber server in erlang, is an excellent example of how to put together a large distributed web based system in erlang.

nothing is perfect, but erlang's benefits to me far outway its rough edges...hopefully, you will experience the same.
good luck...

aristus,
I started looking at erlang in Fall 2004. Its my first serious try at functional programing so I consider my a newbie in functional idioms. However, erlang is not purely functional and is accessible to people with OO experience.
I was a lurker on the erlang-questions maillist for 6 months before making a final decision to start building my apps with erlang. The maillist community is very solid and should be considered a base for your ongoing adoption of erlang.
Here is the maillist and faq link:
http://www.erlang.org/faq.html
If you download any erlang install http://www.erlang.org/download.html, lots of docs are included. There are also some docs not included:
http://www.erlang.org/doc.html
I consider this doc a must read for anyone starting erlang:
http://www.erlang.org/download/erlang-book-part1.p df
The http://www.trapexit.org/ site is a very good portal for docs and the forums are a bi-directional link to the erlang-questions maillist.
The howtos are good to start with:
http://www.trapexit.org/docs/howto/
If you will develop anything requiring a web server, go directly to http://yaws.hyber.org./ Mostly good docs here. Yaws is the most excellent web server written in erlang.
jungerl is a repository of mostly small erlang libraries. Lots of good tools and example code in here:
http://jungerl.sourceforge.net/
ejabberd http://ejabberd.jabber.ru/, a jabber server in erlang, is an excellent example of how to put together a large distributed web based system in erlang.

nothing is perfect, but erlang's benefits to me far outway its rough edges...hopefully, you will experience the same.
good luck...

aristus,
I started looking at erlang in Fall 2004. Its my first serious try at functional programing so I consider my a newbie in functional idioms. However, erlang is not purely functional and is accessible to people with OO experience.
I was a lurker on the erlang-questions maillist for 6 months before making a final decision to start building my apps with erlang. The maillist community is very solid and should be considered a base for your ongoing adoption of erlang.
Here is the maillist and faq link:
http://www.erlang.org/faq.html
If you download any erlang install http://www.erlang.org/download.html, lots of docs are included. There are also some docs not included:
http://www.erlang.org/doc.html
I consider this doc a must read for anyone starting erlang:
http://www.erlang.org/download/erlang-book-part1.p df
The http://www.trapexit.org/ site is a very good portal for docs and the forums are a bi-directional link to the erlang-questions maillist.
The howtos are good to start with:
http://www.trapexit.org/docs/howto/
If you will develop anything requiring a web server, go directly to http://yaws.hyber.org./ Mostly good docs here. Yaws is the most excellent web server written in erlang.
jungerl is a repository of mostly small erlang libraries. Lots of good tools and example code in here:
http://jungerl.sourceforge.net/
ejabberd http://ejabberd.jabber.ru/, a jabber server in erlang, is an excellent example of how to put together a large distributed web based system in erlang.

nothing is perfect, but erlang's benefits to me far outway its rough edges...hopefully, you will experience the same.
good luck...

aristus,
I started looking at erlang in Fall 2004. Its my first serious try at functional programing so I consider my a newbie in functional idioms. However, erlang is not purely functional and is accessible to people with OO experience.
I was a lurker on the erlang-questions maillist for 6 months before making a final decision to start building my apps with erlang. The maillist community is very solid and should be considered a base for your ongoing adoption of erlang.
Here is the maillist and faq link:
http://www.erlang.org/faq.html
If you download any erlang install http://www.erlang.org/download.html, lots of docs are included. There are also some docs not included:
http://www.erlang.org/doc.html
I consider this doc a must read for anyone starting erlang:
http://www.erlang.org/download/erlang-book-part1.p df
The http://www.trapexit.org/ site is a very good portal for docs and the forums are a bi-directional link to the erlang-questions maillist.
The howtos are good to start with:
http://www.trapexit.org/docs/howto/
If you will develop anything requiring a web server, go directly to http://yaws.hyber.org./ Mostly good docs here. Yaws is the most excellent web server written in erlang.
jungerl is a repository of mostly small erlang libraries. Lots of good tools and example code in here:
http://jungerl.sourceforge.net/
ejabberd http://ejabberd.jabber.ru/, a jabber server in erlang, is an excellent example of how to put together a large distributed web based system in erlang.

nothing is perfect, but erlang's benefits to me far outway its rough edges...hopefully, you will experience the same.
good luck...

You may want to take a look at Erlang before getting started on the project. Erlang is a functional programming language that already addresses fault-tolerance, modularity, distributed computing, and other problems you may need to solve. Even if you don't end up using Erlang, you could probably pick up some good design ideas from the (excellent) documentation.

Erlang does provide several mechanisms for interfacing with C code. If you wanted you could use Erlang at a system level, and C++ at a lower level where performance and interoperability with existing code is important.

If lives are at stake, or this is a seriously mission critical system, language selection must be part of the architecture and design - not an arbitrary choice "because my boss said so".

C++ is not an inherently fault tolerant language. There are several that are: Erlang for instance.

Erlang is used in Ericsson's phone systems, is now FOSS, runs under Windows & Linux and is rock-solid, unlike C++. You can even buy support for Erlang if you so desire.

Erlang is used in Ericsson's phone systems, is now FOSS, runs under Windows & Linux and is rock-solid, unlike C++. You can even buy support for Erlang if you so desire.

The "D" name is misleading: it has absolutely nothing to do with the creators of B or C at Bell Labs. The successor of C was Alef(the first latter of a different alphabet) which was used for the original edition of Plan 9[1], and a later descendant by the same team was Limbo(Introduction paper by no other than Dennis M. Ritchie) for the Inferno.

Both Alef and Limbo are much more interesting languages than "D", they keep the clarity and simplicity of C while providing a high level framework for concurrent systems. The only other language with a good concurrency model I know of is Erlang which is quite different but also very interesting and sadly rather under valuated.

uriel

[1] To avoid having to maintain Alef compilers for many architectures Plan 9 is ported to, it was replaced with a C library, libthread, that provides the same concurrency model, for high level programming Limbo replaced it. Libthread, despite it's name is completely different from other threading models and uses CSP to handle concurrency while avoiding locks and many other problems with traditional "threading" systems. Libthread is part of Plan 9 from User Space so you can use it in "legacy" Unix/Linux/BSD systems too(of course Inferno runs on all those systems too...)

Ericsson already has a history of providing open source. See Erlang Does anyone know of open source solutions that the other companies provide?

• Erlang Developed by Ericsson for their realtime telephone servers. Is mature and has concurrent communications and database libraries among other things.
• Oz was made as an implementation of the ideas in the book: "Peter van Roy (2004). Concepts, Techniques, and Models of Computer Programming. MIT Press" Where the idea was that different kinds of programming (concurrency, OO, Logic) could be implemented and cooperate in the same language. Not as mature as Erlang.

- Declarative concurrency (synchronization on logical variables):

• Curry is a extension of the language Haskell and, like Oz, combines different kinds of programming in one language. Unlike Oz, Curry uses declarative concurrecy. Curry is in an even earlier stage of development than Oz.
  
  All these languages are open source and free but they are functional programming languages. The difference betwee

Why would you want to use a CSP-style concurrency model instead of threads? To quote from the occam compiler homepage:

CSP has a compositional and denotational semantics, which means that it allows modular and incremental development (refinement) even for concurrent components. In turn, this means that we get no surprises when we run processes in parallel (since their points of interaction have to be explicitly handled by all parties to these interactions). This is simply not the case for standard threads-and-locks concurrency, which have no formal denotational semantics and by which we get surprised all the time.

In layman's terms, you get concurrency that can be built up from easily understood pieces (instead of a monolithically concurrent system with locks scattered throughout the code), and an underlying theory of concurrency that lets you understand and analyze your design and ensure that it is, for example, free of deadlocks (I've personally created complex networks of 1000+ interacting processes in a dynamically evolving topology, with nary a hitch). And did I mentioned that the context-switching performance of most of these systems is amazingly good?

Mod parent up please, because I think he's (she's) right.

In the future, PC's will have a good Java setup. 1GB of memory and 2 processor cores. One for the program and one for the JVM.

However, to use additional cores for the program as well, not just the JVM, you'll need another programming language like Erlang. This is because Java uses shared memory multiprocessing and Erlang uses message based concurrency. Just like Java prevents memory errors because of it's design, Erlang prevents concurrency errors because of it's design.

But hey, Java is still 2x to 4x faster than Erlang if you don't use 4 cores, so until then, let's use Java's (or even more O.S. Mono's) advantages for the greater good of mankind.

Well, there is always erlang.

I'm kind of surprised it hasn't been mentioned yet.

There's been an interesting discussion on the Erlang mailing list about a possible AJAX implementation. http://www.erlang.org/ml-archive/erlang-questions/ 200509/msg00282.html http://www.erlang.org/ml-archive/erlang-questions/ 200509/msg00320.html

There's been an interesting discussion on the Erlang mailing list about a possible AJAX implementation. http://www.erlang.org/ml-archive/erlang-questions/ 200509/msg00282.html http://www.erlang.org/ml-archive/erlang-questions/ 200509/msg00320.html

The language Erlang is designed in such a way, with such built in rules that it prevents the most bugs from happening at all when you're programming concurrently.

Haskell has excellent potential to be extended with features that will give it concurrent processing bug prevention characteristics. I think there was a fork of Haskell that has a semi-commercial / GPL license called Concurrent Clean which claims to have that extension.

The new star on the firmament that's a candidate for language of the future is the Mozart programming system that is built on the language Oz and also consists of a book with what seems to be insightful stuff about concurrent programming in combination with other types of program construction. Haven't read or used it yet though.