Jump to content

And what about erlang?


Guest eox425

Recommended Posts

Hi guys. And what about erlang?

I've wanted to ask your opinion about this great language for a long time.

So it's concurent, parallel fault-tolerant functional language. The main difference between erlang and his "elder brother" haskell that erlang was designed for telecomunication purposes and real time systems so it has very low latancies in high load systems.

It's only my opinion but I think that erlang-based core would be more stable and it would be easier to make all the concurent stuff.

No this thread is not ralated to ACE holywar.

No I don't want to replace ACE+TBB with boost, but it would be very nice as for me.

Thank's for attention.

Link to comment
Share on other sites

I just wanted to write gen_server in OTP and then use C driver to connect some map handling stuff and do the asio implementation in erlang without ACE

I've used erlang for a couple yaers and can say that the functional way is much better than imperative... less code, less testing, less problems.

About esoteric jokes like Piet brainfuck lolcode and so on...

I think that there is no functional programmers here, and I if you're not familiar with haskell or erlang (elisp maybe, but I hate this damned brackets),

you can't understand all the power of functional programing... Just look here http://lurkmore.ru/images/3/3d/Cmp.jpg

You can do lolposting here, but I insist to be more tollerant to this thread.

I've got a lot of free time and I can waste it in another way, not only on mangos developing...

Link to comment
Share on other sites

IF you know anything about functional programming, then you should know that every new (yeah, they are in) functional language tries to be like apl, but to not look like apl ^^

Most likely some guys here will know about the power of functional programming, but it is just not reasonable to rewrite this project to another language (especially as it is not likely that devs will be good in this language)

Also functional written code is not really good to maintain - that is, it is often quite difficult to read and comprehend.

And mixing the languages in one project is -- I think -- no good idea.

However, as you are willing to actual do some work for mangos with your prefered language, I am very sure you will find usefull things which can be started as contributed things - and then in your language ;) iE as of the new rewrites of maps there was sometimes need for a test-suite

By the way: no language is better than another language - there are advantages and disadvantages in every language

btw2: C++ has this template-thingy, which makes the sorting of a list so simple: myList.sort();

(but ofc the template in C++ becomes a bit ugly to read if used in more complex ways)

Link to comment
Share on other sites

thnx a lot Schmoozerd I haven't heard about ATL, it's very interesting...

I dont want to do full rewriting and reengeneering of the project.

I just want to handle the asynchronous socket stuff, and make the "let it crash" paradigm with OTP.

Map system and pathfinding development is the major branch of the project development for now.

But as for me ACE is very complicated, and using both ACE and TBB to handle concurrency and sockets may be very harmfull for the stability and general performance.

So I want to implement better horizontal scaling posibility with erlang. I don't want to begin the ACE holywar. But Boost may be a better replacement for ACE and TBB.

And, as for me, it's much simplier.

This post is not dedicated to discussion of proframing languges performance or their scalability.

It's not dedicated to HR managment... couse we've got a lack of documentation.

It's not dedicated who gonna write this stuff, who will test it, and who will do the further development.

We've got a lack of filosophical treatment of our main benefits in the project evolution.

Somebody wants to earn some money, someone dicided that it will be a good way to learn C++,

someone wants to be the right guy and prove his own "best way" of developing.

I am just want to make it better.

And I've got some resources and free time.

I have expirienced some very great server building tool, and I want to use it in my favourite project.

I want to hear some critics and to make a list of advantages and disadvantages of patial project rewrite with this (or other) language (or tool like boost).

I hope that the next post will be more meaningfull than the others.

Sorry for bad english. And thanks for attention.

Link to comment
Share on other sites

Yeah I'm just really not sure what you want to do. Do you want to rewrite mangos in Erlang, or do you want to switch mangos from ACE to Boost?

I want to hear some critics and to make a list of advantages and disadvantages of patial project rewrite with this (or other) language (or tool like boost).

The disadvantages are pretty obvious: you are writing it in a language few people on here have even heard of, and making it even less accessible to developers, because then they have to know 2 big and completely different languages instead of 1. I also have yet to see some actual solid examples of why Erlang is a better language for this than C++. The only thing you provided compares one feature that Erlang happens to do well, and is compared with C and not C++, which like Schmoozerd pointed out is much more elegant.

As for the Boost thing, I've never used Boost myself and have never really dug into ACE, so I couldn't say either way. Maybe vladimir or derex or another developer can say more on it. If you want to use Boost with mangos you are free to.

Are you going to work on this?

Link to comment
Share on other sites

Are you going to work on this?

First of all I want to implement realm and world protocol handler with OTP gen_server, but I want to get some consultation about protocols in wow.

Then I'll do some C driver to deliver formated packet structures to the unrewrited part of the mangos.

I dont want to do the full rewriting at the first time. Just protocol handlers, BG, instance and script handlers.

I need to save the ScriptDev compatability.

Then I want to write some speed enhanced mpq extractor, and new map system with OpenCL or CUDA.

I'll try to process all maps with CUDA (OpenCL) optimized algorithms, i mean mmaps and pathfinding, cause we can optimize their size and usage at general.

I mean only extracting and processing to generate some movement patterns for A* or B* algorithms, or general LOS-based pathfinding.

If I'll do some great rewritings and they will be proven by the community as fast and stable, I'll continue to develop the project.

And if my ideas will be banned for the lack of stability, at least we'll have new map implementation. But first of all I need some consultation about the sources, couse some things remains too compilicated for me...

So I need to start working on OpenCL or Cuda enabled mmaps. And erlang DB and protocol handlers.

Link to comment
Share on other sites

Are you going to work on this?

First of all I want to implement realm and world protocol handler with OTP gen_server, but I want to get some consultation about protocols in wow.

Then I'll do some C driver to deliver formated packet structures to the unrewrited part of the mangos.

I dont want to do the full rewriting at the first time. Just protocol handlers, BG, instance and script handlers.

I need to save the ScriptDev compatability.

Then I want to write some speed enhanced mpq extractor, and new map system with OpenCL or CUDA.

I'll try to process all maps with CUDA (OpenCL) optimized algorithms, i mean mmaps and pathfinding, cause we can optimize their size and usage at general.

I mean only extracting and processing to generate some movement patterns for A* or B* algorithms, or general LOS-based pathfinding.

If I'll do some great rewritings and they will be proven by the community as fast and stable, I'll continue to develop the project.

And if my ideas will be banned for the lack of stability, at least we'll have new map implementation. But first of all I need some consultation about the sources, couse some things remains too compilicated for me...

So I need to start working on OpenCL or Cuda enabled mmaps. And erlang DB and protocol handlers.

Link to comment
Share on other sites

Are you going to work on this?

First of all I want to implement realm and world protocol handler with OTP gen_server, but I want to get some consultation about protocols in wow.

Then I'll do some C driver to deliver formated packet structures to the unrewrited part of the mangos.

I dont want to do the full rewriting at the first time. Just protocol handlers, BG, instance and script handlers.

I need to save the ScriptDev compatability.

Then I want to write some speed enhanced mpq extractor, and new map system with OpenCL or CUDA.

I'll try to process all maps with CUDA (OpenCL) optimized algorithms, i mean mmaps and pathfinding, cause we can optimize their size and usage at general.

I mean only extracting and processing to generate some movement patterns for A* or B* algorithms, or general LOS-based pathfinding.

If I'll do some great rewritings and they will be proven by the community as fast and stable, I'll continue to develop the project.

And if my ideas will be banned for the lack of stability, at least we'll have new map implementation. But first of all I need some consultation about the sources, couse some things remains too compilicated for me...

So I need to start working on OpenCL or Cuda enabled mmaps. And erlang DB and protocol handlers.

Link to comment
Share on other sites

I have never worked with erlang, but have done quite a few things in haskell. For that reason, I thought erlang is one of the 10000+ language forks and the first sentence in the first post sounded like "hey! this erlang looks cool, let's rewrite everything to erlang!". As some people have little-to-none brain processing power, such threads also appear and I thought this is just another of them.

If you mean it seriously, please accept my apology, I don't know any person who often works with functional languages and it's interested in mangos development at the same time.

I've never worked with CUDA on the programming level, but doesn't CUDA need newer nvidia card? Can it be emulated for systems with no graphic card (ie. servers)?

Link to comment
Share on other sites

So I need to start working on OpenCL or Cuda enabled mmaps. And erlang DB and protocol handlers.

Good, start from here.

I would avoid CUDA, since you are getting stuck with essentially a proprietary language that only works on a few pieces of hardware. OpenCL is a much better choice because it's fully supported in all modern GPUs and OSes and can fall back on CPU support if there are no compatible GPUs available or for extra power.

As for rewriting the protocal handlers in Erlang, sure, you can do that, and I'd be interested in what comes out of it.

Link to comment
Share on other sites

I haven't worked with OpenCL for a long time, so cuda implementation would be simplier task.

Cuda is faster on mem replacement and analysis on Nvidia videocards, cause CL has no full support for NV PTX assembler.

OpenCl is not fully supported on NV8xxx serries. Cuda enabled devices are starting on nv gf8400.

About ATi. I haven't worked with them...

If I'll write with Cuda, you can use NV cards only. With OpenCl you can use both ATi and NV cards but it's slower on NV.

So I'll chouse Cuda for a first time.

To freghar.

Yes, I want to do partial rewriting, to provide some clustering support and new map implementation for pathfinding.

I have nothing to do during my working semester.

Hakell and erlang can't be simly compared with each other.

Erlang if much faster on clusters and SMP systems (lightweight processes).

Haskell has better (faster) IO implementation (monads).

Erlang is about 98% percent compatable with ahmdal's law, and haskell only about 60%.

C++ Boost for example is about 84% compatable... and it's very good result, but erlang is more scallable on clusters.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use