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

91–100 of 129 posts

Re: Actix – Actor Framework for Rust

#91

Post by whatshisface »

shawnz wrote: post #14
vbezhenar wrote: post #11

Earlier quoted context omitted.

You can run every actor in a separate thread or even in a separate machine, making the whole system highly scalable. Whether you'll consider that a new paradigm or not, is question of definitions.

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.

Re: Actix – Actor Framework for Rust

#92

Post by Rusky »

undecisive wrote: post #81
burntsushi wrote: post #70

Earlier quoted context omitted.

A small but crucially important clarification: it wasn't just that there was a lot of `unsafe` code, but that some portion of it was unsound . You can read more about what I mean by unsound in this context here: https://docs.rs/dtolnay/0.0.7/dtolnay/macro._03__soundness_b...

Interesting - thanks for sharing that. Though that article does make things a little clearer, I get the impression we should really have three circles on a venn diagram - essentially, I'm decoupling the concepts of "unsound" and "bug": - Bug - i.e. some unintended action of a piece of code - unsound - i.e. code that can be used (or abused) to produce unsafe effects - unsafe-bleed - i.e. code that cannot be proven to…

In the most recent issue, there was in fact demonstrated "unsafe-bleed," in the sense that client code could hit undefined behavior by using public safe APIs a particular way.

Re: Actix – Actor Framework for Rust

#93

Post by brentjanderson »

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…

Erlang OTP 21.2 introduced the idea of `persistent_term`, which is a data structure any process can read from at the expense of being costly to modify. This provides a nice alternative to locks, since you can have a single actor/process responsible for handling writes (and deciding when to flush those writes, triggering a GC pause on processes depending on the term) but any number of actors reading from that persistent term at full-speed.

Re: Actix – Actor Framework for Rust

#94

Post by kevinmgranger »

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?

Re: Actix – Actor Framework for Rust

#95

Post by kevinmgranger »

macintux wrote: post #64
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

Typically parallelism is particularly interesting for performance, and the (usually?) shared-nothing architecture of the actor model is not conducive to high performance computing.

Shared-nothing usually means a lot of unnecessary copying-- but rust lets you have safe transfers of data ownership, usually without copying. I wonder if that would make for a uniquely performant actor framework. (Depends on the implementation and user code, of course.)

Re: Actix – Actor Framework for Rust

#97

Post by rofrol »

polskibus wrote: post #79

Out of curiosity - actix seems to be very performant compared to actor frameworks implemented in other languages - would it be a good fit to implement a database using it? For example mapping worker pool and workers to actors?

I would rather use linux io_uring https://www.reddit.com/r/rust/comments/f06y7m/comment/fguw9a...

Re: Actix – Actor Framework for Rust

#98

Post by sakian »

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…

Aren't they connected by the idea of active objects? https://en.wikipedia.org/wiki/Active_object

Re: Actix – Actor Framework for Rust

#99

Post by burntsushi »

undecisive wrote: post #81
burntsushi wrote: post #70

Earlier quoted context omitted.

A small but crucially important clarification: it wasn't just that there was a lot of `unsafe` code, but that some portion of it was unsound . You can read more about what I mean by unsound in this context here: https://docs.rs/dtolnay/0.0.7/dtolnay/macro._03__soundness_b...

Interesting - thanks for sharing that. Though that article does make things a little clearer, I get the impression we should really have three circles on a venn diagram - essentially, I'm decoupling the concepts of "unsound" and "bug": - Bug - i.e. some unintended action of a piece of code - unsound - i.e. code that can be used (or abused) to produce unsafe effects - unsafe-bleed - i.e. code that cannot be proven to…

I don't have the time or desire to answer that question. That would require a level of scrutiny into specific PRs and details that I don't think is productive to go into. I think my clarification stands on its own. Gratuitous use of `unsafe` is bad on its own, and unsound `unsafe` use is also bad on its own. They are two different categories of problems. Both were present in actix. These weren't the only issues, but others have addressed those. My only point was to clarify that the issue wasn't just frequency. Soundness was also an issue.

Whether this only impacts actix developers or whether it impacts users of actix is, I grant, an important question in order to asses just how much you should freak out about any particular soundness problem. (As dtolnay points out, sometimes you don't need to freak out at all. So my statement includes "zero amount." But I am intentionally conveying a bias here: some level of freak out is probably appropriate in a high profile ecosystem level project for Rust specifically. IMO.)

Re: Actix – Actor Framework for Rust

#100

Post by jerf »

zackmorris wrote: post #84
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?

To me, the biggest difference is that the actor model has no shared memory between classes like with object-oriented programming. I'd actually like to see OO programming where classes are completely isolated, but to my knowledge, that doesn't really exist. Go, Elixir and Erlang come close. UNIX shell with isolated processes communicating over streams -> Actor model Pretty much every C-style language with all of their…

Elixir/Erlang/BEAM, as far as I know, semantically don't just come close, they arrive. I say "semantically" because there are some optimizations for things like large binaries so the system isn't literally copying a lot of them around unnecessarily, but semantically, BEAM processes are isolated from each other entirely.

Go doesn't come close; technically it's just another shared-state programming language. Culturally, it tends to use more sane concurrency features, and the channels are nice and all, but technically there is no isolation between goroutines.

With discipline, you can program Go with an actor mentality and it's fairly effective. I do it all the time, leaning on my years of experience in Erlang and some Haskell, which teaches you how to build systems that work that way. But you do need non-trivial discipline as the language provides rather less help with than I'd like.

Post reply on HN