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

111–120 of 129 posts

Re: Actix – Actor Framework for Rust

#111

Post by fpgaminer »

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.

I think the other comment is conflating a previous kerfuffle, not the most recent one (the older event was about a criticism of Actix's previously prolific use of unsafe rather than a specific bug). From my recollection of the most recent brouhaha:

Someone found a bug in some unsafe code and created a Github issue about it. The maintainer requested a PoC to show that the issue wasn't theoretical. A PoC was provided. Maintainer agreed it was a bug, but wanted a different solution than the provided pull-request. The maintainer was then harassed by a handful of Reddit/Twitter for various reasons. Maintainer nuked the GH issue. The internet-harassment escalated, so the maintainer deleted the repo.

The outcome is that a few days later the maintainer re-released the repo but assigned a new maintainer and is no longer publicly involved in the project.

Re: Actix – Actor Framework for Rust

#112

Post by captain_crabs »

habitue wrote: post #103

Highly recommend Bastion if you're looking for a Rust Actor library / runtime. It uses async/await etc, and has supervision trees and restart strategies taken straight from Erlang/OTP https://docs.rs/bastion/0.3.4/bastion/ https://github.com/bastion-rs/bastion

would you even suggest this over riker?

Re: Actix – Actor Framework for Rust

#113

Post by estebank »

Arnavion wrote: post #107
dmm wrote: post #102

Earlier quoted context omitted.

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&mo…

A more stylistic pattern for this is to give the binding a type so that the coercion of the if/else expression works automatically instead of using `as`.

Also, there's work being done so that this won't be needed by deferring evaluation of expressions until the whole body has already been evaluated so that inference with the naïve code will work at some unspecified time in the future.

Re: Actix – Actor Framework for Rust

#114

Post by ahasani »

smallstepforman wrote: post #109
shanxS wrote: post #89

Earlier quoted context omitted.

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

Yes they are, atom is in isolation, cell has membrane, we have a body we have isolation and encapsulation in physics/chemistry/biology. In actor model message passing is interaction. Since you mentioned game, check out https://github.com/aeplay/kay, which is the isolation "objects" for https://github.com/citybound/citybound "physics engine". On multiple bank accounts, well an account is an actor, so there is no problem there, please have a look at http://proto.actor/blog/2017/06/24/money-transfer-saga.html

Re: Actix – Actor Framework for Rust

#115

Post by butterisgood »

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.

Parallel compute middleware is often based on message passing when the parallel computer is a cluster. See MPI.

Re: Actix – Actor Framework for Rust

#116

Post by dantodor »

I'm amazed on how much discussion digressed to actix-web. Understandable, seen the latest happenings there, but still... I tried quite a while ago Actix, coming from Erlang/Elixir and Scala/Akka. While the cognitive load of using it was not high, when I started my first test, I noticed one core being maxed out, and all others sleeping, which was kinda unusual for me. I asked why, and the author answered that it uses an event loop, so if you want it otherwise, go away and use something else, like Riker... So I went away :) ... I would assume this kind of behaviour has been corrected meanwhile (I mean the library, not the comms), because otherway, it's just a Node written in Rust. My 2c :)

Re: Actix – Actor Framework for Rust

#117

Post by anthony_doan »

wwweston wrote: post #110
edejong wrote: post #18

Earlier quoted context omitted.

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?

I learn about Actor model via Elixir/Erlang.

A good place to start is perhaps learning Elixir and eventually move to OTP and it's actor model.

Actor are just processes in Erlang/Elixir (underlying implementation is a thread that doesn't share anything) that isolate logic (self contained) and if it goes down it doesn't take any thing else down. So it's OO that way. It helps that functional paradigm good practices is small compose-able function that does one thing. You compose these functions into a logic and wrap it in these processes and treat them like objects.

Re: Actix – Actor Framework for Rust

#118

Post by anthony_doan »

Isn0gud wrote: post #13
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?

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. Object oriented programming is a language feature while the Actor paradigm can be build on top of OOP to ease the mental burden of parallel programming.

It's a nice approach to concurrency.

It doesn't guarantee parallelization. Concurrency is a precursor and a requirement for parallelization but it doesn't guarantee it.

Re: Actix – Actor Framework for Rust

#119

Post by habitue »

captain_crabs wrote: post #112
habitue wrote: post #103

Highly recommend Bastion if you're looking for a Rust Actor library / runtime. It uses async/await etc, and has supervision trees and restart strategies taken straight from Erlang/OTP https://docs.rs/bastion/0.3.4/bastion/ https://github.com/bastion-rs/bastion

would you even suggest this over riker?

I haven't used Riker, is it good?

Re: Actix – Actor Framework for Rust

#120

Post by _-___________-_ »

mamcx wrote: post #57
_-___________-_ wrote: post #5

Earlier quoted context omitted.

I wouldn't call Actix the most mature, but it's definitely the one that gets talked about the most. I built a fairly complex backend directly on top of Hyper[0] (it doesn't even involve that much glue, really) in 2016 and have updated it as Rust and Hyper have matured. It's actually a delight to work on, and I brought a new hire on board recently who had no trouble getting up to speed, since everything is just straig…

> I wouldn't call Actix the most mature Surely? I try several other for replace my .NET core project, and Actix is the only one that barely get there. Which other handle without much fuzz: - Auth (big!) - Routing with state and db pooling - Forms - Templates - Encode/Decode all stuff (query string, headers, etc) - Allow to inject middle-wares - Have (at least) the bare minimum of functionality like gzip encoding - An…

Actix has a lot of features, but to me that's not the same as maturity. I don't want one "batteries-included" framework, I want components (preferably mature and relatively boring) with well-defined interfaces that I can use together to build my backend.
Post reply on HN