🔒 Locked

For everyone who wants to make an MMO

Started by flodihn Oct 8, 2009 at 2:09 PM 31 replies 11.5k views

Original Post

Oct 8, 2009 at 2:09 PM

For everyone who wants to make an MMO Since the launch of WOW there has been a increase of people/indie projects that wants to create their own MMO. Most of them are where I was about 6-7 years ago, I had this idea of an MMO but no idea how to implement it, for the worse I didn't even research about what tools I should use before I started to develop. I seriously overestimated my own abilities, the scope of an MMO project and the limitations the tools I were using were imposing on my project. My path of failure to make an MMO: I was no noob, I had several years of programming experience in C, C++, Java and Python, and I knew a lot about design patterns, program architecture and database design, still my first tries was doomed to failure because I was building the MMO in the same way as I always made programs. With this I mean I used a program that was built to run on one computer with one CPU and executing a main loop that iterates over objects to update them. I begun developing my game in python (which was my favorite language at the moment), believing I would have something that working within a year. For about 4 years I developed about 2 different server architectures. 1: The first was to test my abilities. It was a 2d space game using a python server and python (pygame) clients. The clients could fly around in with tie-fighters on a starmap and fire green lasers. I felt I was ready to make the same in 3d. 2: The second game I manged to create a virtual world which you could explore, with physics and everything. At this stage 4 years had passed, I realized I would never be able to make a real MMO engine of out my code, it couldn't handle many players at the same time because it couldn't handle concurrency very well, I had barely started looing into distributing my servers to other machines, which is a huge and complex task. I had two choices: 1: Continue developing software I knew never would scale up to handle massive amount of players. I could drop the massive part and write software for a smaller amount of players. I would probably ended up with something like the game love (http://www.quelsolaar.com/love/index.html) that can handle about 300 players per sharded server (because the servers are developed in C or C++). 2: Finding better tools to build a better platform that my previous ones. I choose number 2. I had learned about Erlang on the University but never realized the strengths with the language until I begun researching for best languages for servers. I started to develop, from scratch again a new platform in Erlang, using the languages built-in support for concurrency and distribution. After 2 more years I finally have platform that gracefully spread over a cluster in a way I would never could dream of making in C++, Java or Python, unless I had a whole staff and a budget of 100 million dollars and could spend 10 years developing what Erlang already has. Conclusion: If you want to make an MMO forget getting something workable in a year (unless it's buggy, crashing and doesn't scale), if you use the right tools it will ateast take 3 years before you have something to show, add a few more years and you might have something ready for beta testing. To have a scalable platform, forget writing servers in C++/Java, Python or any other imperative language (Stackless Python and Scala, neither help you to distribute). Erlang is the only language at the moment that is feasible to write non-sharded MMO platforms with a small team or one man team. Erlang does a lot of magic for you, but still you will have to deal with pretty complex stuff and distribution problems. Erlang does not remove those problem but makes them far more easily to solve. Learning the language Erlang can be done in a week or two (it is seriously the smallest language I know), but what makes Erlang powerful is the OTP library which is sort of framework for developing applications. OTP is complex and will take time to learn, but it's worth it when you feel the power of the language and how much more easily you can scale compared to other languages. Be prepared to spend at least one year progressing your skill with Erlang and OTP, the good thing is that you can start developing your servers and learning OTP at the same time. And to speed up the development on the client side, use a 3d renderer like Ogre3d, Irrlicht or Torque. My personal favorite is Ogre3d since it does only rendering (you can plug in your own physics, GUI etc), it's also very stable and has a great API. Epilouge After years of hard working, spending about 2 - 8 hours of my spare time programming I finally have a seed for an MMO and just about to start developing the fun parts, world building tools, night/daytime system, skills system etc. The best part is that the platform I developed by myself that is far more advanced and powerful than that what WOW or EvE Online have. AFTER YEARS OF DEVELOPMENT, I HAVE NOT EVEN STARTED MAKING THE ACTUAL GAME YET! Now I face other difficulties, such as managing a team, graphics (concept art, 3d models) which I need other people to help me with. If you posting on these forums how to use the winsocks to write server/client MMO, or how to implement threading so your server can multitask, I hope my experiences can help you, so you don't have to spend 6 years of your life developing software you will have to scratch. [Edited by - flodihn on October 8, 2009 3:22:43 PM]

Momoko_Fan

Oct 8, 2009 at 5:47 PM

I myself have made an MMO once. It was 2D and in Java. I used two libraries, one for networking (JGN) and one 2d game engine (JGame). Suffice to say, it was very productive. The two libraries took care of a lot of work and I was able to concentrate on features, game play and the world.

So, let this be a suggestion to anyone who wants to make an MMO: Start small with 2D and (maybe) move to 3D later on.

ApochPiQ

Oct 8, 2009 at 7:30 PM

I'm going to go ahead and kick this over to For Beginners, since I think it'll have a much better chance of reaching the intended audience there.

Rycross

Oct 8, 2009 at 7:55 PM

A bit off-topic, but I'm actually interested in Erlang. Do you have some real-world metrics on how well Erlang is handling your MMO load? You seem to strongly recommend it in your conclusion.

Antheus

Oct 8, 2009 at 8:08 PM

Quote:
1: Continue developing software I knew never would scale up to handle massive amount of players. I could drop the massive part and write software for a smaller amount of players. I would probably ended up with something like the game love (http://www.quelsolaar.com/love/index.html) that can handle about 300 players per sharded server (because the servers are developed in C or C++).
2: Finding better tools to build a better platform that my previous ones.

This is your only mistake: you should *always* choose one.

And a well meant advice: "Only a poor craftsman blames the tools".

Quote:
The best part is that the platform I developed by myself that is far more advanced and powerful than that what WOW or EvE Online have.

Erlang is essentially CSP - exactly the same thing can be done in C++ (Ice, CORBA, boost asio), Java (RMI, CORBA), or any other language. The shared-nothing architecture is relatively easy to scale, but eventually suffers from communication overhead (it turns out it's managable given current concurrent user counts).

Erlang will scale - but not in a way you will need it to.

But you are young, and once you get involved in real world projects, you will learn about why choosing 1) is the most important thing.

Quote:
A bit off-topic, but I'm actually interested in Erlang. Do you have some real-world metrics on how well Erlang is handling your MMO load?

It scales just as well as equivalent server written in other languages. The problems come from elsewhere - how to design the database, how to split processing.

It's the real-time part that complicates things. If you don't need real-time response, you could use Hadoop + whatever language and you get effectively infinite scalability (just add boxes).

Shared state is the killer. Erlang scales flawlessly due to its shared nothing architecture - but MMOs are inherently about shared state. Hence Erlang works great for extreme web sites, where shared state doesn't need to be deterministic.

Another problem that can arise is data passing. As soon as you have large state, it can happen that you inadvertently start passing around megabytes of data just for a single message.

jackolantern1

Oct 8, 2009 at 10:39 PM

Nice post, but honestly if a newcomer is interested in making their own MMORPG, they should just look into one of several available MMORPG engines. These include Realm Crafter, Torque MMOKit (although the compatible versions of TGE will no longer be available soon), Multiverse, and several other 2D solutions. I would only suggest rolling up your sleeves and coding from the ground up if you want to learn how MMORPGs *are made*, not if you want to make a game. As you said, it is 3 years later and you have not started making the game yet.

flodihn

Oct 9, 2009 at 12:35 AM

Quote:
And a well meant advice: "Only a poor craftsman blames the tools".

I think you are wrong, the tools you choose is very important, why don't you see any MMO's developed in assembler?
Ofcourse, if you are a good programmer you can do it, but real question is how easy it can be done and how long time would it take.

Quote:
Erlang is essentially CSP - exactly the same thing can be done in C++ (Ice, CORBA, boost asio), Java (RMI, CORBA), or any other language. The shared-nothing architecture is relatively easy to scale, but eventually suffers from communication overhead (it turns out it's managable given current concurrent user counts).

What you mean with CSP, Constraint satisfaction problem?

Quote:
It scales just as well as equivalent server written in other languages. The problems come from elsewhere - how to design the database, how to split processing.

How to design "the database"? If you design your game around one database, like Eve Online it will become a bottleneck. If you want want to scale you can not have one database, you must localize the data. My area servers, each have their own database, thus naturally splitting up the data into geographic spaces.

Quote:
It's the real-time part that complicates things. If you don't need real-time response, you could use Hadoop + whatever language and you get effectively infinite scalability (just add boxes).

Looks interesting and feasible if you have experience in those kind of libraries, if you are new do distribution I am pretty sure Erlang will be much more easier way to achieve distribution.

Quote:
Shared state is the killer. Erlang scales flawlessly due to its shared nothing architecture - but MMOs are inherently about shared state. Hence Erlang works great for extreme web sites, where shared state doesn't need to be deterministic.

Actually Erlang has shared state, the difference is how you handle it. For example instead of letting "objects" change each other states directly (or though locks), Erlang does it by message passing.

Quote:
Another problem that can arise is data passing. As soon as you have large state, it can happen that you inadvertently start passing around megabytes of data just for a single message.

If you seriously passing messages of megabytes in your system, something is wrong with your design. I can not think of any situation where I want to to this in my servers.
It would be interesting to know what you did why you did something like that. In Armstrong book "Programming Erlang" he states it's very important that you rather send many small messages, than a single large message.

As you said yourself, don't blame the tool you are using:)

supamike

Oct 9, 2009 at 1:44 AM

I guess one thing people tend to forget when they decide they want to make the next WoW, is that Blizzard had essentially been developing it for 13 years ie. from their incorporation in '91, to its launch in '04.

They built an experienced team and had financial success through the release of Warcraft1, 2, 3, StarCraft, D1, D2. In particular Battle.net would have taught them a lesson in the issues with networking and scalability associated with MMOs. All this before they were anywhere near building WoW (well, they were probably working on it when they released W3 in '02).

My point is it didn't just pop up out of nowhere.

So someone, or a group of people, who want to make a WoW killer without this breadth of experience, and IP built up over decades, is in for a tough time.

To quote Frank Pearce of Blizzard at the recent Austin GDC,

Quote:

To maintain one online game (WoW) requires 20,000 computer systems, 1.3 petabytes of storage, more than 4,600 people.

WoW servers have 13,250 total server blades and 75,000 total CPU cores and 112.5 terabytes of RAM running the servers

My advice to people wanting to make MMOs, would be put it to one side for now, get your team to start making quality non MMO games, and build from there.
You'll still enjoy the ride, make some money along the way, and have a dedicated fan base for your MMO in 10 years time when you start building it.

btw thanks for sharing flodihn :)

Cygon

Oct 9, 2009 at 2:57 AM

Quote:
Original post by Antheus
Quote:
1: Continue developing software I knew never would scale up to handle massive amount of players. I could drop the massive part and write software for a smaller amount of players. I would probably ended up with something like the game love (http://www.quelsolaar.com/love/index.html) that can handle about 300 players per sharded server (because the servers are developed in C or C++).
2: Finding better tools to build a better platform that my previous ones.

This is your only mistake: you should *always* choose one.
And a well meant advice: "Only a poor craftsman blames the tools".

Yes, I believe that's what commercial IT projects tend to do. And most IT projects succeed brilliantly, right?

There's other well meant advice out there: "Choose the right tool for the job" and perhaps "Stop beating a dead horse".

I can't say anything about Erlang, but I believe obtaining the same soft-threading and RPC capabilities in C++ would entail quite a bit of work. And in my naive understanding, its "shared nothing" architecture would not require you to copy around potentially large states, let alone the whole world.

Several Erlang processes could be responsible for sections of the world, when a client sends a "move 10 units east", the client handler process just informs the process that's the authority for the world section that "player 123 wants to move 10 units east", the authority responds "player 123 blocked after 5 units" and the client handler process communicates that back to the client.

But as I said, I haven't used Erlang, so maybe I'm off here.

From what I can see here, the original poster has done his homework and I fully expect him to understand the implications of choosing Erlang.

flodihn

Oct 9, 2009 at 4:40 AM

Quote:
Original post by Rycross
A bit off-topic, but I'm actually interested in Erlang. Do you have some real-world metrics on how well Erlang is handling your MMO load? You seem to strongly recommend it in your conclusion.

You can check out the video "Load Balancing Part II" on my site, www.next-gen.cc.
The videos might not play properly in Quick Time or Windows Media Player, but they display correct in VLC.

For short, I had 2000 spammer objects, each sending out one message to all other objects, this generates 4 000 000 messages per second in the area.
I had two servers running the same area, (1 Ghz Celeron laptops with 512 MB RAM). If you view the video you can see how my system move objects from the loaded server to the unloaded server.
This process of moving an object between machines does not affect its functionality at all.

Even thou the system was heavy under load, I hade no problem moving around in the world. I think I will make a new movie that also shows how I can create/change objects while the servers are under stress.

Edoc

Oct 9, 2009 at 10:10 AM

How to identify a MMO F.A.I.L Project:

(You meet any/all of these requirements)

* The project leader has no skills/trade. He may think he's a programmer, writer, or better yet-- the 'Idea Man', but in reality, has no professional experience in any field whatsoever, and has never completed a real project.

* Volunteer projects that have 'revolutionary ideas' (or even complete freedom), that boasts to rival multi-million dollar game companies.

* Fan-games. Anything that uses story, graphics, music etc. from other sources.. like Mario, Final Fantasy, Pokemon, Anime and tv shows. These game projects are F.A.I.L for obvious reasons.

* The project has no design document. And team members don't even have a clear TODO list. This is more common than you might think.

* The team members only know each other by 'internet aliases'. EX: Programmer- Darkknight, Artist- BlueDragonX, Writer- Ghostgirl22

* No money for development.

rolkA

Oct 9, 2009 at 10:46 AM

Quote:
Original post by Momoko_Fan
I myself have made an MMO once. It was 2D and in Java. I used two libraries, one for networking (JGN) and one 2d game engine (JGame). Suffice to say, it was very productive. The two libraries took care of a lot of work and I was able to concentrate on features, game play and the world.

So, let this be a suggestion to anyone who wants to make an MMO: Start small with 2D and (maybe) move to 3D later on.

how many players did you have on a regular basis ?

M stands for Massive, if it's not then it's not an MMO; period.

[Edited by - rolkA on October 9, 2009 2:46:26 PM]

Edoc

Oct 9, 2009 at 11:03 AM

Quote:
Original post by rolkA
Quote:
Original post by Momoko_Fan
I myself have made an MMO once. It was 2D and in Java. I used two libraries, one for networking (JGN) and one 2d game engine (JGame). Suffice to say, it was very productive. The two libraries took care of a lot of work and I was able to concentrate on features, game play and the world.

So, let this be a suggestion to anyone who wants to make an MMO: Start small with 2D and (maybe) move to 3D later on.

how many players did you have on a regular basis ?

M stands for Massive, if it's not then it's not an MMO ; period.

Yeah, It sounds like he's describing an ONLINE game.

MMO:A massively multiplayer online game (also called MMOG or simply MMO) is a video game which is capable of supporting hundreds or thousands of players simultaneously. By necessity, they are played on the Internet, and feature at least one persistent world.

lithos

Oct 9, 2009 at 2:37 PM

I think you could scare away more people just by showing the expenses of server hosting alone. And making them realize no one cares about the project until you have something playable.

Kylotan

Oct 12, 2009 at 8:03 AM

Quote:
Original post by flodihn
I think you are wrong, the tools you choose is very important, why don't you see any MMO's developed in assembler?

But you do see MMOs developed in Java, and Python. Erlang has many benefits but so do these other languages. And they can quite easily use the same mechanisms - you just have to choose to code it that way. Erlang is a good choice but it's not the only good choice.

Quote:
What you mean with CSP, Constraint satisfaction problem?

He means Communicating Sequential Processes.

Quote:
How to design "the database"? If you design your game around one database, like Eve Online it will become a bottleneck. If you want want to scale you can not have one database, you must localize the data. My area servers, each have their own database, thus naturally splitting up the data into geographic spaces.

Many successful MMOs just have 1 game database per shard. Of course there are often separate in-memory representations of the data across the cluster but that's a bit different. "All programming is an exercise in caching" as Terje Mathisen said. You just have to know what to cache and at what level.

flodihn

Oct 12, 2009 at 11:13 AM

Original post by Kylotan
Original post by flodihn
I think you are wrong, the tools you choose is very important, why don't you see any MMO's developed in assembler?
Quote:
But you do see MMOs developed in Java, and Python. Erlang has many benefits but so do these other languages. And they can quite easily use the same mechanisms - you just have to choose to code it that way. Erlang is a good choice but it's not the only good choice.

I am not saying that you can't scale with other languages than Erlang, I am saying that no other language comes with distribution as a core feature, therefore is much more work to get good scalability in other languages. I wouldn't say you can quite easily scale with the same mechanics, it will takes several man-years of development to make for example C/C++ scale and distribute like Erlang does.

Yes there are online games in Java, like WURM Online, which is a next generation "MMO" with an well developed skill system, terrain that can be lowered/raised by players etc. Not suprising at all they they have scalability problems.

EvE online is based on Stackless Python, and is running a huge database cluster as their backend storage, they also have scalability issues and is solving their SQL bottleneck by spending lots of money on better hardware, instead they could had a scalably solution from start and spend the money to developing features in the game instead.

Quote:
What you mean with CSP, Constraint satisfaction problem?

He means Communicating Sequential Processes.

Ah thanks. I think he just used Erlang for concurrency and missed the distributing part.

[Edited by - flodihn on October 12, 2009 2:13:36 PM]

Kylotan

Oct 13, 2009 at 5:28 AM

Quote:
Original post by flodihn
I am not saying that you can't scale with other languages than Erlang, I am saying that no other language comes with distribution as a core feature, therefore is much more work to get good scalability in other languages. I wouldn't say you can quite easily scale with the same mechanics, it will takes several man-years of development to make for example C/C++ scale and distribute like Erlang does.

That's not really true. The core of Erlang is just communication by message-passing, with copies of data sent by value, with pattern matching on the receiving end. Implementing a basic system like that is maybe a few weeks' work in C++, or a couple of days in Python. And that's why there are several good implementations of similar systems. Scala has actors and the 'receive' method to permit very similar operation. With Python you might use any number of free libaries for this sort of thing, such as PARLEY, pysage, Candygram.

The important thing is not the Erlang implementation as such. The important thing is the knowledge of how to effectively use shared-nothing distributed systems, and how to handle complex transactions such as trade when the traders are on different nodes.

It also comes from knowing how actor A can make a decision about actor B without having a full copy of actor B to query. Should it hold redundant state? (Prone to data consistency errors, and is memory-expensive.) Or should it query for each required property as needed? (Prone to process errors, incurs significant latency.)

Quote:
EvE online is based on Stackless Python, and is running a huge database cluster as their backend storage, they also have scalability issues and is solving their SQL bottleneck by spending lots of money on better hardware, instead they could had a scalably solution from start and spend the money to developing features in the game instead.

You seem to just be saying that anything not built with Erlang is inherently an unscalable solution. Erlang is written in C. Therefore anybody programming in C could implement the same features as the Erlang developers did. The problems these developers have are not language issues but architectural issues. Or perhaps knowledge issues.

Even so, it's a bit pointless to complain that EvE has trouble scaling. That's like me complaining that Bill Gates could be richer. 90% of MMOs, even AAA ones, won't need to go as far as EvE has. Of the 10% that do, most of them will be aware of the issues anyway. There are tradeoffs with every design decision and opting for an Erlang style model doesn't come without any cost.

flodihn

Oct 14, 2009 at 2:53 PM

Original post by Kylotan

Quote:

That's not really true. The core of Erlang is just communication by message-passing, with copies of data sent by value, with pattern matching on the receiving end. Implementing a basic system like that is maybe a few weeks' work in C++, or a couple of days in Python. And that's why there are several good implementations of similar systems. Scala has actors and the 'receive' method to permit very similar operation. With Python you might use any number of free libaries for this sort of thing, such as PARLEY, pysage, Candygram.

No, here you are wrong. I stated before that distribution is core feature of the language, since you don't seem to take my word for it I'll have to show you:)

Start an Erlang node on computer1

user@computer1:~$ erl -sname node1

Start an Erlang node on computer2

user@computer2:~$ erl -sname node2

Then you can from the node on computer1 to this:

rpc:call(node2computer2, erlang, now, [])

This code, from node1 will call the function now() on node2, retreiving the time on computer2. In my experience, Erlang is the only language that comes with a node system and built in rpc-library to easily call remote functions other nodes.
Erlang comes with its own name services for discovering nodes on the network, the service is started automatically when you start a node. There are many things Erlang will provide for you in a distributed environment, things you will have to make yourself of use a third party library for in other languages.

Quote:

The important thing is not the Erlang implementation as such. The important thing is the knowledge of how to effectively use shared-nothing distributed systems, and how to handle complex transactions such as trade when the traders are on different nodes.

It also comes from knowing how actor A can make a decision about actor B without having a full copy of actor B to query. Should it hold redundant state? (Prone to data consistency errors, and is memory-expensive.) Or should it query for each required property as needed? (Prone to process errors, incurs significant latency.)

I agree on this.

Quote:

You seem to just be saying that anything not built with Erlang is inherently an unscalable solution. Erlang is written in C. Therefore anybody programming in C could implement the same features as the Erlang developers did. The problems these developers have are not language issues but architectural issues. Or perhaps knowledge issues.

I thought I made it clear when I said "am not saying that you can't scale with other languages than Erlang, I am saying that no other language comes with distribution as a core feature, therefore is much more work to get good scalability in other languages".

[Edited by - flodihn on November 19, 2009 11:53:28 AM]

Kylotan

Oct 15, 2009 at 5:34 AM

Quote:
Original post by flodihn
No, here you are wrong. I stated before that distribution is core feature of the language, since you don't seem to take my word for it I'll have to show you:)

No, I know full well it is a core feature of Erlang and not elsewhere. (Although I believe Scala's Actors are part of the core library.) What I'm saying is that it doesn't matter. When you make claims such as "Erlang is the only language at the moment that is feasible to write non-sharded MMO platforms with a small team or one man team.", that is incorrect when you can have the same functionality (slightly different syntax, but no more verbose) in Python with this code snippet:

import pysage

Terms like 'only' and 'feasible' are very strong. It's important that people know they are exaggerations.

Quote:
I thought I made it clear when I said "am not saying that you can't scale with other languages than Erlang, I am saying that no other language comes with distribution as a core feature, therefore is much more work to get good scalability in other languages".

I hope that the above code example is not too much work...

flodihn

Oct 17, 2009 at 10:12 AM

Original post by Kylotan

Quote:

Quote:

Original post by flodihn
No, here you are wrong. I stated before that distribution is core feature of the language, since you don't seem to take my word for it I'll have to show you:)

No, I know full well it is a core feature of Erlang and not elsewhere. (Although I believe Scala's Actors are part of the core library.)

First you said Erlang only provided concurrency. Then I showed you it also provides distribution. And now you changed your mind and and say you knew that erlang provided distribution as a core feature. If you didn't know distribution was a core feature of Erlang it is OK to say so, there is no one who knows everything. Changing your mind like that doesn't seem so professional.

After your own contradiction you said something about Scala's Actor being part of the core library, I have no idea what you mean with this since Erlang and Scala are two completely different things. The only thing they have in common is that Scala provides Erlang-like concurrency and pattern matching in Java.

Quote:
What I'm saying is that it doesn't matter. When you make claims such as "Erlang is the only language at the moment that is feasible to write non-sharded MMO platforms with a small team or one man team.", that is incorrect when you can have the same functionality (slightly different syntax, but no more verbose) in Python with this code snippet:
import pysage

No, this will not give you the same functionality as Erlang, here is the differences:

Erlang is a language designed with concurrency, distribution and fault-tolerance in mind, from scratch.
Pysage is just a module to a language that brings concurrency to a langauge built with object orientation and simple syntax in mind.

Erlang has been in development for 22 years (started 1987).
From what on the pysage webpage, the project has been active in 2 years (started 2007).

When looking up Erlang at Wikpedia, you see that a number of big companies and opensource projects use it, Apache Foundation, Facebook, Amazon and Yahoo, just to mention the biggest.
When looking up Pysage at Wikipedia I found nothing.

There seem to the 3 contributors/developers maintaing pysage.
I actually didn't find how many is maintaining Erlang, but I am quite sure much more than 3.

The Erlang has a good documentation, just as expected by programming language these days.
Pysage has a very sparse documentation and few examples.

Pysage seems to support putting actors in different groups, each group runs its own thread. If you want to use all cores/CPU's evenly you have to make sure to balance this yourself by spreading different actors in different groups.
The Erlang scheduler does this automatically for you, you only need to spawn process and Erlang will put it in a thread, and if needed move processes between threads to even the load.

I tried to find out if the pysage had removed the PIL (Python Intepreter Lock) for multicore support, else it would be quite waste of power and processing power to run on modern CPU's (which probably has two or more cores).

Pysage only brings concurrency (if the PIL is still in place, even a broken concurreny) to Python. If you want to send a message to an actor located on another machine, you have to first serialize the message with some pysage function and even worse, you have to know what machine to deliver the message.
Here is a quote from the "Networking" article in the pysage wiki:

Quote:

packing can be useful for sending messages across network. This may prove to be useful in the future when pysage supports cross processing message queuing.

If you look at their API you see a connect function in the actor which needs a host and port specified:
http://www.bigjinfo.com/pysage/pysage.system.ActorManager-class.html
Therefore I belive my statements are true, I found no documentation on the webpage to to send messages to actors on other computers.

In Erlang just need the process id to deliver a message to a another process:

ProcessId ! MyMessage

You don't need to know if ProcessId is an Id of a local process or a process located on another machine in the network. You also don't need to care on what machine the process is running, Erlang will make sure the message is delivered.

Since Pysage is a module in Python, what happens if one actor crashes, I didn't find any specific about this on the homepage but normal behaviour is that the whole thread (Pysage group) crashes, which means all other actors on the same groups also crashes.
In Erlang, if one process crash it doesn't affect any other process.

The last and most important difference is that unlike Pysage, Erlang also provdides distribution and fault-tolerance.

Quote:

Terms like 'only' and 'feasible' are very strong. It's important that people know they are exaggerations.

Yes these are very strong words, but I stand up for them.

At last I want to say that I feel this thread is becomming personal, it seems like you are trying to defend you favourite language Python.
I used to be a Python evangelist too, I used it for everything (even servers), now with more experience I know better. There is not one language (yet) that is good for everything. Python still is a great language, which I use a lot but not server software.

Here is the link the pysage webpage: http://code.google.com/p/pysage/

Here is a link about Erlangs fault-tolerance: http://www.erlang.org/doc/design_principles/part_frame.html
And a link about distributed applications in Erlang: http://www.erlang.org/doc/design_principles/distributed_applications.html#9

[Edited by - flodihn on November 26, 2009 3:12:31 PM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.