Erlang is THE BOMB

Discussion in 'OT Technology' started by Peyomp, Jan 20, 2009.

  1. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    I'm learning Erlang, and I have to say that its the most fun I've had programming in a long time.

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

    Its a functional/concurrent programming language built for concurrent programs across many cores and machines. Erlang provides all the features (and limitations) you need for highly reliable, highly scalable, highly concurrent systems. Ericsson developed it for telecom applications, and it has been running some systems - without interruption, since 1998. Kinda easy when you can upgrade the code LIVE without shutting anything down. Everything about Erlang is freaking amazing.

    Example: wanna send a message from one PID to another?

    ServerProcess ! {pause, 10},

    That sends ServerProcess the message (a tuple): {pause, 10}. Try that in any other language! Tying PIDS together so that one monitors another and takes over if it fails... trivial.

    Know what else? You can spawn 100s of thousands of Erlang PIDS on a notebook PC. They are not OS threads or PIDs and have very little overhead.

    Its a bit hard to think in a purely functional way, and thats the main challenge I'm having so far. I'm finding it harder than the cross from procedural to OO was.

    Anyone ever code Erlang?
     
  2. kingtoad

    kingtoad OT Supporter

    Joined:
    Sep 2, 2003
    Messages:
    55,923
    Likes Received:
    11
    Location:
    Los Angeles
    Nope.
     
  3. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    Sounds like it would be great, coupled with DLLs written in C++. Include the DLL in an Erlang class, write some code to pass data between the class and the DLL, then spawn as many as you need and use Erlang to communicate between them.

    Based on what you said, though, it doesn't sound like a very practical solution to write entire applications in it; maybe it's best used as "glue", like you said about Perl a while back.
     
  4. whup

    whup I wish you had children and.. so that I could step

    Joined:
    Feb 12, 2007
    Messages:
    1,603
    Likes Received:
    0
    Erlang is pretty good. Functional languages are rapidly gaining in popularity because they apply naturally and beautiful to multi-core and distributed systems.

    A lot of people don't know much about Erlang or its impact (Facebook Chat being the example most people will have used before).
     
  5. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    Its not glue, its the core of reliable concurrent services. It just isn't for the kind of applications that you're thinking of. DLL's are of no use, and Erlang actually performs on-par with C/C++ in highly concurrent apps because nothing locks or blocks and the Erlang kernel is very good at what it does.
     
  6. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    I was messing with Perl/POE and it was a lot of fun, but I was having shared memory issues and it got to the point where I was like... fuck this I'm just rewriting it in Erlang.
     
  7. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    I was talking about making it easy to write the shit. You said yourself it's hard to think about programming the way Erlang's developers intend, so why not just write the code for each process template in C++ and use Erlang to handle forking instead?

    Anyway, message-passing is certainly superior to shared memory spaces, provided you can spare the CPU power (and who can't these days), but having no locking at all can be dangerous if you abuse it. Locking exists because people abused shared memory; it wasn't added for shits and giggles.
     
  8. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    Shared memory doesn't scale, period. That way lies madness.

    As to hardness... its not Erlang's fault. I've just never coded in a functional language before. OO was hard as hell until I learned to think in OO. This is no different. If I already knew Haskell, this would be easy.

    So I'm not sure why you would try and wrap a limited functional language in an OO language... that would defeat the purpose of Erlang.

    But, you're right: you wouldn't do a GUI in Erlang. You could code that in whatever.
     
  9. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    Shared certainly doesn't scale indefinitely, that's for sure. Though I have to think that the message-passing must use temporarily-shared memory when you get down to the nuts and bolts.

    I wasn't saying you should wrap Erlang in C++, I was saying you should wrap C++ in Erlang. Do the jobs in C++, and coordinate them in Erlang.
     
  10. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    It won't work. The whole point of Erlang is the limits it places on you to make everything safe for concurrency.

    As to the nuts and bolts, I don't pretend to know how the Erlang kernel works, just the behavior it exhibits.
     
  11. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    Oh, I didn't realize it was that restrictive. Oh well.

    It's interesting that you say I'm a bad engineer because I'm not always eager to get my hands dirty, but you're willing to use Erlang without any idea how its runtime operates.
     
  12. Limp_Brisket

    Limp_Brisket New Member

    Joined:
    Jan 2, 2006
    Messages:
    48,422
    Likes Received:
    0
    Location:
    Utah
    :uh:
     
  13. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    If I had to understand how its runtime operated to use it, I wouldn't use it. I actually have real problems to solve ;)

    You're a bad engineer because you said use C++ instead of learn functional programming. Thats why you still code in VB.
     
  14. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    My point is very similar to yours. I don't need to know the intricacies of coding in whatever web language is hot this month in order to design a good website, I just need to run the design past the programmer and pay attention when he says "yeah, that piece is going to be a bitch to implement this way, it would be easier if we did it this other way instead." Then, if other parts of the design don't dictate that that one piece needs to be implemented the hard way, then I can change it. And regardless of whether revision is necessary, the design is laid out ahead of time, and nobody has to go back months or years from now and try to figure out why the hell that one piece was implemented in such a difficult way for no apparent reason -- BECAUSE THE REASON WAS DOCUMENTED TO START WITH. I'd call that a real problem that got solved.

    I code in VB on my own time because none of my personal projects matter in the big scheme of things.
     
  15. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    Code:
    -module (message_router).
    
    -compile(export_all).
    
    route_messages() ->
        receive
            {send_chat_message, Addressee, MessageBody} ->
                Addressee ! {recv_chat_message, MessageBody};
            {recv_chat_message, MessageBody} ->
                io:format("Received: ~p~n", [MessageBody]);
            % This is a catch all, for messages we have no specified
            Oops ->
                io:format("Warning! Received: ~p~n", [Oops])
        end,
        % In erlang we loop via recursion
        route_messages().
    
    
    Code:
    2> c("message_router").
    {ok,message_router}
    3> P = spawn (message_router, route_messages, []).
    <0.41.0>
    4> P.
    <0.41.0>
    5> P ! {shut_your_whore_mouth, "Test"}.
    Warning! Received: {shut_your_whore_mouth,"Test"}
    {shut_your_whore_mouth,"Test"}
    6> P ! {send_chat_msg, P, "Hello sucker!"}.
    Warning! Received: {send_chat_msg,<0.41.0>,"Hello sucker!"}
    {send_chat_msg,<0.41.0>,"Hello sucker!"}
    7> P ! {send_chat_message, P, "Hello sucker!"}.
    Received: "Hello sucker!"
    {send_chat_message,<0.41.0>,"Hello sucker!"}
    
    
    You ever done IPC so easily? FUN!
     
  16. Peyomp

    Peyomp New Member

    Joined:
    Jan 11, 2002
    Messages:
    14,017
    Likes Received:
    0
    Check this out, between two machines:

    Machine 1:
    Code:
    erl -sname bar -setcookie erlang
    
    ([email protected])3> net_adm:ping([email protected]).
    pong
    
    
    Machine 2:

    Code:
    erl -sname foo -setcookie erlang
    
    ([email protected])3> net_adm:ping([email protected]).
    pong
    
    rpc:call([email protected], erlang, date, []).
    {2009,2,7}
    
    
    Its just amazing how little code there is to multi-node systems using IPC.

    Code:
    send_chat_message(Addressee, MessageBody) ->
        global:send(?SERVER, {send_chat_message, Addressee, MessageBody}).
    
    Thats the entire function to route chat messages to/from clients on multiple machines.

    Imagine doing strings in C, then manipulating them in Perl. Perl is so much more powerful for string manipulation than C, right? Well, Erlang has that kind of jump in power for concurrent systems, its that kind of jump. It includes most of the challenges you would face in other languages doing networked/concurrent systems as language features. The hard parts 'just work' and you can build on top of that - all those problems solved!
     
    Last edited: Feb 7, 2009

Share This Page