Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Actix – Actor Framework for Rust

github.com

Post reply on HN
Print view View original

101–110 of 129 posts

Re: Actix – Actor Framework for Rust

#101

Post by eweise »

shawnz wrote: post #6

What is the difference between the actor model and object oriented programming? It seems to me like they are basically the same paradigm but with all the names changed, and some additional restrictions like all messages being async and objects only being able to process one message at a time. Why is it necessary to create a whole new paradigm just to enforce such a style?

I haven't looked at this framework but from the one I am familiar with, once you make the calls async, the objects can live anywhere, locally or remote. Also, you may have to assume that messages don't get processed and thus need to handle that case. The upside is that distributing your app becomes a configuration issue instead of a coding one. This is nice because with microservices, the seams need to be decided upfront and its hard to refactor if you get it wrong.

Re: Actix – Actor Framework for Rust

#102

Post by dmm »

kevinmgranger wrote: post #94
dmm wrote: post #58

The naming is a little confusing here. This is Actix the actor model library, not "Actix web" the web framework that's usually discussed. Originally "Actix web" depended on Actix the actor library, but no longer. Though they can be used together. And I think websockets still require actors? I'm using both Actix and Actix web for a personal project. I like it a lot and think the actor model is good fit for application…

> Even if you box the returned Future, you end up having to use futures::Either a bunch That's really strange. A Boxed future is the end-all-be-all of not caring about the underlying type. Would you mind sharing a snippet of code that shows where you need both a Boxed future and Either?

You're probably right, I must be missing something. I'm also still on futures 0.1 because I'm still porting it to std::futures.

Here's an example of what I was discussing:

https://github.com/dmm/exopticon/blob/c40d14c80c150ef6270732...

The idea is that I want to implement a relative ptz move on a camera but some cameras have a broken relative move implementation so in that case we instead use a continuous move + a delay + a continuous stop. The final case is when a camera has no ptz it returns Http::NotFound.

Re: Actix – Actor Framework for Rust

#104

Post by paulddraper »

hopia wrote: post #69
alecmg wrote: post #48

Earlier quoted context omitted.

Actor model is good for parallelisation. Each Actor and its message queue can be processed separately from everything else. There should be no side effects except new messages sent or new actors spawned. So a pool of worker actors can absolutely work in parallel. In fact now I'm curious if Actix supports that

Actor model really is for concurrency, not for parallelism. For pure parallel computing it introduces unnecessary overhead because of the message passing. That overhead in turn hurts performance, which really is the only reason you'd want to compute in parallel.

> it introduces unnecessary overhead because of the message passing.

Inter-process and inter-machine parallelism do that anyway.

Re: Actix – Actor Framework for Rust

#105

Post by samatman »

hopia wrote: post #85
samatman wrote: post #83

Earlier quoted context omitted.

Concurrency allows for parallelism. It's common to conflate parallel programming with so-called embarrassingly parallel tasks, but this isn't accurate. For tasks which may be executed in parallel but aren't working on different regions of a single state, actors are an excellent choice.

Right, but isn't what you say exactly concurrency instead of what we normally consider parallel computing, at least on a single machine? Depending on the implementation/runtime you may or may not need something like threads, which are a good concurrency primitive, for parallel computing.

I'm not entirely sure what the disconnect is here, but I'll give it a shot.

Parallel computing is simply running more than one aspect of a computation simultaneously, it requires multiple processors/cores, or SIMD. Concurrency is doing more than one thing 'at a time', and this generally includes things like callbacks (to allow more work to be done while waiting on an action) and preemptive threading (which may or may not involve true parallelism).

Concurrency is an opportunity to work in parallel, one which may or may not be achievable. I consider threads a bad concurrency primitive, because they're too low-level and hard to get right, and this becomes even worse when one runs threads in parallel.

Actors, which are a share-nothing concurrency model based on message passing, are a good concurrency primitive. Among the reasons for this are that one can put them on threads and not have to deal with locking and unexpected mutation. You can treat them as an implementation detail that happens below the level the programmer must concern themself with.

This means they're good for running in parallel, as well, which is quite tractable on a single machine given that it has multiple cores (mine has eight).

Colloquially we sometimes say 'parallel computing' when referring specifically to so-called 'embarrassingly parallel' tasks, like some rendering algorithms, where one may bring as many cores to bear on the task as one has available.

But concurrency is always an opportunity for parallelism, and an actor model allows one to take that opportunity given that other aspects of the runtime don't stand in the way. And parallel computing is simply running more than one computation at the same time, it doesn't by itself imply anything else about the algorithm.

Re: Actix – Actor Framework for Rust

#106

Post by M2Ys4U »

whatshisface wrote: post #91
shawnz wrote: post #14

Earlier quoted context omitted.

Isn't that basically the same as remote method invocation in OO systems?

The big difference is that you can pass an object to a method of another object, but you can't send an actor through a message channel. That jives with threads because a thread can't climb in to the stack and get passed through another thread.

You should be able send a handle to an object through a message channel, though.

Re: Actix – Actor Framework for Rust

#107

Post by Arnavion »

dmm wrote: post #102
kevinmgranger wrote: post #94

Earlier quoted context omitted.

> Even if you box the returned Future, you end up having to use futures::Either a bunch That's really strange. A Boxed future is the end-all-be-all of not caring about the underlying type. Would you mind sharing a snippet of code that shows where you need both a Boxed future and Either?

You're probably right, I must be missing something. I'm also still on futures 0.1 because I'm still porting it to std::futures. Here's an example of what I was discussing: https://github.com/dmm/exopticon/blob/c40d14c80c150ef6270732... The idea is that I want to implement a relative ptz move on a camera but some cameras have a broken relative move implementation so in that case we instead use a continuous move + a de…

If you have

    if cond {
        Box::new(future_a)
    }
    else {
        Box::new(future_b)
    }
then by default, the type of the first Box will be concrete Box rather than Box, which is why you'll get a type error that Box != Box

You'll need to coerce the first expression to Box. The compiler will auto-coerce the other one.

    if cond { Box::new(future_a) as Box> } else { Box::new(future_b) }
See https://play.rust-lang.org/?version=stable&mode=debug&editio...

(This auto-coercion also applies to other situations where the type of an expression must match the previous one's, such as with a slice literal where the first element dictates the types of the rest.)

You don't need to coerce if the compiler can infer that the whole if-expr must be of Box type. This happens when the if-expr is being returned directly and thus must have the same type as the function's return type, or it's being assigned to the binding and the binding has been previously inferred to have (or explicitly has) Box type. You can test this in the playground by returning the if-expr directly instead of binding it to `result`.

Re: Actix – Actor Framework for Rust

#108

Post by sdegutis »

Qwuke wrote: post #50
DeedsMoraine wrote: post #46

Earlier quoted context omitted.

I doubt that has much to do about the merits of either language as a web back-end, and it's more about people not wanting to consider Haskell at all.

I absolutely agree - there's a lot of explaining when you have to choose the less traveled path, and it hurts there's a perception that both languages are intended for 'academic' or 'niche' purposes. Why Rust is considered over Haskell in one of the organizations I've been with is because it has the performance/memory usage characteristics of C/C++, which is a requirement for certain services. Though for many project…

I think the fact that Haskell is more math than programming might also be related to that. I've been programming for a decade and still don't understand Haskell.

Re: Actix – Actor Framework for Rust

#109

Post by smallstepforman »

shanxS wrote: post #89
smallstepforman wrote: post #87

Actors in principle (isolated objects assigned to threads) sound great until you need to SHARE data, then you enter a new universe of compromises where you need locking mechanisms (for performance), but no language semantics support it natively. Pony introduced reference capabilities but that still created a cludge for those times you needed synchronous access. There is no model yet where locking primitives are assoc…

> ... sound great until you need to SHARE data ... If by "share" you mean one writer and others with read-only access, then staleness of data is a question. In java we have volatile for that, I think there is a similar keyword in C++. However, you'll have to maintain the invariant of "one writer and others with read-only access". If you don't need absolute latest version, you can do message passing/pubsub etc. If by…

Unfortunately, our objects are not isolated, they interact with the world, and often need to be shared when we cannot copy the resource (performance). Eg. a (partitioned) rendering surface may be written simultaneously, a physics engine needs to know what objects are in the game world, multiple bank accounts need to be updated simultaneously, etc. By design is not always possible to sequence, some transactions must be atomic across multiple objects.

Re: Actix – Actor Framework for Rust

#110

Post by wwweston »

edejong wrote: post #18
shawnz wrote: post #6

What is the difference between the actor model and object oriented programming? It seems to me like they are basically the same paradigm but with all the names changed, and some additional restrictions like all messages being async and objects only being able to process one message at a time. Why is it necessary to create a whole new paradigm just to enforce such a style?

Your question is interesting from the perspective that the actor model could be seen as the precursor to modern object oriented programming. Both the actor model as defined by Carl Hewitt and the early object computational models as they are defined by Alan Kay (Smalltalk) originated during the same period and are based on similar philosophies of computation. However, on the object oriented model track, due to practi…

If I'm only following about half of what you're saying (I'm familiar with Smalltalk and the OO model, I don't know what the actor model is, I don't know what "locality" means), what's a good place for me to start?
Post reply on HN