How Do Erlang Actors Differ from Oop Objects

How do Erlang actors differ from OOP objects?

In other words, when I am passing messages between Erlang actors, how is it different than when I'm passing messages between Ruby objects?

The difference is that in traditional languages like Ruby there is no message passing but method call that is executed in the same thread and this may lead to synchronization problems if you have multithreaded application. All threads have access to each other thread memory.

In Erlang all actors are independent and the only way to change state of another actor is to send message. No process have access to internal state of any other process.

Actor model vs object oriented model

Disadvantages of OO model:

1. Traditional OOP languages weren’t designed with concurrency. It was
   very easy to introduce race conditions since it was using a shared
   state.
2. The programmers had to identify and fix all possible problem
   areas by using locking mechanisms.
3. Locking is easy to implement for simple programs. But as the programs got complex, the implementation of locking has also become complex.

Actor model overcomes the problem by using share nothing model so that concurrency is not affected and locking mechanism is not needed.

Erlang (Functional Programming) vs Object Oriented Programming in terms of thinking

I would use records:

-record(post, {title, date_created, body, comments = []}).
-record(comment, {created_by, date_created, content}).

Then if you want to use mnesia as database:

Post = #post{title = "", body = "", date_created = erlang:universaltime()},
mnesia:transaction(fun() -> mnesia:write(Post) end).

To add a comment:

Comment = #comment{created_by = "", content = "", date_created = erlang:universaltime()},
mnesia:transaction(fun() ->
    [Post] = mnesia:read(post, Title),
    PostWithNewComment = Post#post{comments = [Comment | Post#post.comments]},
    mnesia:write(PostWithNewComment)
end).

I haven't tested the code, but this is what I would do. Also I assumed that each title is unique.

Scala - why actor model is an example of mixing OO and functional programming?

"I don't quite understand why the author said actor concept cannot be implemented without unifying OO and functional programming."

The authors did not say "Functional Programming" in that quote (although Scala does take a number of such concepts as the chapter address later on), but rather..

.. In fact the actor concept shown previously could not have been implemented without this unification of functions and objects.

The major implication of this is that functions are First-Class and as such can be passed around as any other type of value - this in turn makes functions suitable for callbacks, such as "reactions".

However, the example shown really does not show "unification of functions and objects" well at all, even if they are unified underneath (even the pattern matching yields a function). As such, the quote should be taken more as a bait on a fishing line..

[Scala is a] language that grows on you

Basic Explanation of Actors in Erlang

I think you would help yourself if you didn't confuse actors with Erlang processes. You started with Wikipedia's description of Actor model only to seamlessly start writing about Erlang processes, like if it was one and the same. Actor model is a mathematical model which can be implemented in many different ways, including a pure C or C++ low-level implementation. On the other hand, Erlang processes are lightweight preemptive language features that allow to run a vast amount of processes in parallel much more effectively than it would be possible using native system processes or even threads. It happens that they are modelled after the mathematical model, but it was a design decision based on specific requirements.

I think it would all fit better together if you discussed briefly the Actor model as a mathematical model on its own and only then how it has been implemented in Erlang, pointing out any differences and features specific to Erlang.

Scala Actors - any suggestions when converting OOP based approach?

Answering your questions:

2) Your domain model (including shops, orders, buyers, sellers, items) should be described with immutable case classes. Actors should exchange (immutable) commands, which may use these classes, like AddItem(count: Int, i: Item) - AddItem case class represents command and encapsulates business entity called Item.

1) Your protocol, e.g. interaction between shops, orders, sellers, buyers etc., should be encapsulated inside actor (one actor class per protocol, one instance per state). Simply saying, an actor should manage any (mutable) state, changing between requests, like current basket/order. For instance, you may have actor for every basket, which will contain information about choosed items and receive commands like AddItem, RemoveItem, ExecuteOrder. So you don't need actor for every business entity, you need actor for every business process.

In addition, there is some best practices and also recommendations about managing concurrency with routers.

P.S. The nearest JavaEE-based approach is EJB with its entities (as case-classes) and message-driven beans (as actors).

What is actor model in context of a programming language?

I think Wikipedia sums it up best:

The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent. [snip] The Actor model is about the semantics of message passing.

Actor pattern - what it exactly constitutes

That definition of an Actor actually seems a little restrictive. It certainly doesn't handle Erlang-style actors (or I believe Scala-style actors). In my experience, an actor is something that:

• Sends and receives messages (each actor has a mailbox)
• Shares no mutable memory with other actors
• Is scheduled based on the whims of the runtime. An actor could be given its own thread, but it is more likely that several actors participate in co-operative multithreading in a single thread, or maybe even participate in pre-emptive multithreading.

But fundamentally, an actor is a free-running chunk of code that can receive messages from its environment and can send messages back out to its environment.

Actors are used any time that you need lots (and lots) of stateful little processes. Networking is a common use case, because you don't want to allocate a whole thread to each connection. You want something lighter-weight, so you allocate an actor to each connection, and then schedule the actors on a smaller pool of threads. But networking is certainly not the only use of an actors.

In Erlang, an actor is a function. The function probably tail-calls itself (so it's basically an infinite loop), and it probably has a clean way to self-terminate (the infinite loop has a "break" condition). The loop typically waits for a message from the system, processes it, and then sends out messages to the rest of the system. The Erlang OTP library has some abstractions that eliminate the need to even write the loop, so an OTP actor is implemented as a set of callbacks. In that way, an OTP actor looks a lot like an object.

---

Related Topics