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

61–70 of 129 posts

Re: Actix – Actor Framework for Rust

#61

Post by aphexairlines »

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…

Can't you use async/await with the compat libraries for futures and for tokio?

https://tokio.rs/blog/2019-12-compat/

Re: Actix – Actor Framework for Rust

#62

Post by jlouis »

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 think the key point is that most actor models, at least the ones I know, are truly concurrent with preemption, whereas most models based on OO are sequential. There is only one thread of execution in the OO program, whereas there is no notion of this in an actor system. All processes execute at the same time, so to speak.

There are also some points with the messaging being truly asynchronous, so you can't rely on the order in which messages arrive, usually subject to certain constraints. Erlang, for instance, require that between any two pairs of processes, order is preserved in the messages.

Also, creating a new actor creates a new thread of execution inside that actor. This is not the same as creating a new object.

Re: Actix – Actor Framework for Rust

#63

Post by tinco »

_-___________-_ wrote: post #9
ncmncm wrote: post #4

Can somebody please summarize the outcome of the recent kerfuffle? I don't mind which way it came out, but it seems worth knowing what it was. I absolutely don't want any even-slightly-inflammatory answer.

This is from memory, I would welcome any corrections. Actix was written with a lot of unsafe code [0], which some people considered unnecessary and potentially dangerous in a web framework. In some cases the unsafe code may have been performing better than equivalent safe code. In other cases, it was possible to rewrite with safe code without losing performance. People submitted patches to replace unsafe code with sa…

For non-rusties: unsafe means turning off Rust's advanced safety features, reducing its safety level to that of C or C++. Which is to say, it's as safe as almost all software you're using right now. Of course, one usually turns off the safety features because one is trying to do something tricky to squeeze out performance or achieve some low level feat, so it's also an indicator that something is dangerous is going on.

In your C++ you might add a comment explaining the behaviour you're relying on to convince any reader of the correctness of your code. The cool thing about Rust is that anywhere you don't have the unsafe block, you're (theoretically) certain there's no tricky business going on without even having to read the code.

There was a lot of commotion in the community because many rustaceans take a lot of pride in having this safety features. They took offense at disabling those features, risking Rust's reputation of safety, for seemingly meaningless goals (such as winning the TechEmpower benchmarks). It's not disabling the safety features that makes the code faster btw, it's the tricks you're allowed to do when the safety is off that might yield performance improvements.

Re: Actix – Actor Framework for Rust

#64

Post by macintux »

alecmg wrote: post #48
microtonal wrote: post #20

Earlier quoted context omitted.

In the Actor model, all function calls are async and have no return value, between the Actors. Each Actor is single threaded (OOP) program. It provides a nice approach to deal with parallel programming. I guess you mean 'concurrent programming', right? I haven't seen actors used a lot for parallelism.

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.

Re: Actix – Actor Framework for Rust

#65

Post by macintux »

brucenanner wrote: post #53
imtringued wrote: post #49

Earlier quoted context omitted.

Although I'm not sure what you really mean by "remote method invocation", the idea of remote method invocation in OO systems should be impossible or incredibly difficult considering the semantics of a method call. Method calls are synchronous and they are not allowed to fail under any circumstance. But in the context of distributed systems you have to choose between at most once or at least once delivery which are se…

Not nearly impossible. Was put in the jdk like 20 years ago. RMI: https://en.m.wikipedia.org/wiki/Java_remote_method_invocatio...

It’s impossible to make RMI behave exactly like local method invocation. It introduces many error cases and performance challenges you don’t normally have to consider.

Re: Actix – Actor Framework for Rust

#67

Post by jerf »

brucenanner wrote: post #53
imtringued wrote: post #49

Earlier quoted context omitted.

Although I'm not sure what you really mean by "remote method invocation", the idea of remote method invocation in OO systems should be impossible or incredibly difficult considering the semantics of a method call. Method calls are synchronous and they are not allowed to fail under any circumstance. But in the context of distributed systems you have to choose between at most once or at least once delivery which are se…

Not nearly impossible. Was put in the jdk like 20 years ago. RMI: https://en.m.wikipedia.org/wiki/Java_remote_method_invocatio...

There have been dozens or hundreds of things called "remote method" or "remote procedure" or "remote function" invocation. However, not a single one of them has overcome the fundamental problem that you can not have something that is semantically identical to the function call presented by programming languages, because programming language functions simply do not have the concept that you are accessing it over a network, and they take heavy and critical advantage of the resulting simplifications.

Someone more clever than wise may stand up and point out that technically even a local function call is unreliable in many of the same ways that a network call is. However, even if many of the same problems can theoretically arise, the distribution of the problems are fundamentally different, which is why you do not guard every single function call in your program for all the network-type errors, and it generally works, whereas if you program that way in a networked environment, it generally does not work.

Personally I've come to prefer messages very strongly to "RPC" as the foundation of a system. Messages can trivially implement an RPC-like system, but RPCs can not implement a message-like system. Even if you implement an RPC called "SendMessage", you're still adding synchronization on the RPC system sending over the call and waiting for the response. Among other things, but that's the big one.

Re: Actix – Actor Framework for Rust

#69

Post by hopia »

alecmg wrote: post #48
microtonal wrote: post #20

Earlier quoted context omitted.

In the Actor model, all function calls are async and have no return value, between the Actors. Each Actor is single threaded (OOP) program. It provides a nice approach to deal with parallel programming. I guess you mean 'concurrent programming', right? I haven't seen actors used a lot for parallelism.

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.

Re: Actix – Actor Framework for Rust

#70

Post by burntsushi »

_-___________-_ wrote: post #9
ncmncm wrote: post #4

Can somebody please summarize the outcome of the recent kerfuffle? I don't mind which way it came out, but it seems worth knowing what it was. I absolutely don't want any even-slightly-inflammatory answer.

This is from memory, I would welcome any corrections. Actix was written with a lot of unsafe code [0], which some people considered unnecessary and potentially dangerous in a web framework. In some cases the unsafe code may have been performing better than equivalent safe code. In other cases, it was possible to rewrite with safe code without losing performance. People submitted patches to replace unsafe code with sa…

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...

Post reply on HN