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

81–90 of 129 posts

Re: Actix – Actor Framework for Rust

#81

Post by undecisive »

burntsushi wrote: post #70
_-___________-_ wrote: post #9

Earlier quoted context omitted.

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

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 be safe at compile time, or even potentially code that can be proven to be unsound, that a third-party developer could legitimately use without knowing it was unsafe/unsound.

The question I'm curious about is what the proposed PRs fixed. It's clear they didn't fix a bug; the API used was part of the undocumented internals (afaik), and all internal uses of the code were reportedly clean.

It maybe "fixed" an unsoundness, future developers of the project may indeed have misused this code and received undefined behaviour as a result (again, I don't know how common or uncommon the particular misuse would be in the rust community)

I don't know whether this fixed an unsafe-bleed though; whether a third party has access to these objects and has the ability to combine them in such a way as to produced undefined behaviour.

My question to you is: is this a Bug, such that the code did not perform as expected; Is there a bleed of unsafety here, where the permissions model of rust allows access outside the crate to these implementation details; or is it just unsoundness - and if so, could the unsoundness have been mitigated some other (more performant) way?

Re: Actix – Actor Framework for Rust

#82

Post by 3fe9a03ccd14ca5 »

I’m really excited about this project. Using Akka was one of those things that made distributed/parallel execution just “click”. Particularly useful was being able to draw your architecture the same way one might draw an organization on a whiteboard. Everyone can quickly understand what happens and who is responsible for what.

Re: Actix – Actor Framework for Rust

#83

Post by samatman »

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.

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.

Re: Actix – Actor Framework for Rust

#84

Post by zackmorris »

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 caveats -> Object-oriented model

Re: Actix – Actor Framework for Rust

#85

Post by hopia »

samatman wrote: post #83
hopia wrote: post #69

Earlier quoted context omitted.

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.

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.

Re: Actix – Actor Framework for Rust

#86

Post by zamalek »

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?

The way I like to think of it is: actors combine objects (allocated objects, specifically) and threads. You wouldn't really allocate a thread per object, but that's an implementation detail. Message passing etc. all follow from the restrictions that arise due to objects being threads.

The restrictions you talk about are the key advantage of the actor model. OOP is extremely powerful, and nobody seemingly knows how to use that power responsibly. Actors introduce just enough rails to drive you into the pit of success.

Just like Rust imposes restrictions to improve the reliability and security of software, Actors impose restrictions that improve the human comprehension and reasoning of software architecture.

Re: Actix – Actor Framework for Rust

#87

Post by smallstepforman »

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 associated with resource handles.

Re: Actix – Actor Framework for Rust

#88

Post by devmunchies »

dragonsh wrote: post #35
EugeneOZ wrote: post #30

Earlier quoted context omitted.

Oops, I'm writing web backends in Rust 5 years already and didn't know it's not "viable" yet.

Yes probably viable for you as an individual, this does not collate into viable for most. It’s still a niche inside a niche. People are writing web backend in Haskell for decades, it is a viable choice for very specific niche of web development. Rust has miles to go before it can reach even that stage. At present elixir has much bigger eco-system than Rust.

Event Crystal, which isn't even 1.0 yet, is easier to build a web server. The rust team just hasn't focussed on web programming as much as systems programming.

Its even the main example on Crystal's homepage: https://crystal-lang.org

Re: Actix – Actor Framework for Rust

#89

Post by shanxS »

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 "share" you mean multiple writers, I'll have to question your design decision. Why do multiple threads have to write to same memory location? Most of the time, you can get away with partitioning/sharding.

If you disagree, I'd like to know why?

Re: Actix – Actor Framework for Rust

#90

Post by buckminster »

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…

> OO programming where classes are completely isolated

That sounds like COM, especially the Automation subset.

Post reply on HN