Actix – Actor Framework for Rust • Hacker News Board

Re: Actix – Actor Framework for Rust

#41

Post by s_c_r » Thu, Feb 13, 2020, 12:44 PM UTC

_-___________-_ wrote: post #5

jamil7 wrote: post #2

Whats the state of Rust if I wanted to get into it for backend development? I've looked briefly into Rocket and liked it but didn't delve too deep, I understand Actix is one of the most mature?

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…

That's good to know! I got burned pretty bad trying to switch away from actix-web to one of the other frameworks (rocket, gotham, warp) after the whole kerfuffle and lost my taste for Rust as a backend web language as a result. Seeing your experience makes me want to try again with only hyper! I've always heard it was too "low level" and never gave it a proper look as a result.

Re: Actix – Actor Framework for Rust

#42

Post by hopia » Thu, Feb 13, 2020, 1:00 PM UTC

microtonal wrote: post #20

Isn0gud wrote: post #13

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

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.

Yeah actor model is a good fit for distributed concurrency. For single machine concurrency, let alone parallel computing it may not be the ideal choice.

Re: Actix – Actor Framework for Rust

#43

Post by dragonsh » Thu, Feb 13, 2020, 1:01 PM UTC

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?

OOP and Actor model followed parallel paths of evolution: the Actor Model was created by Carl Hewitt based on the message passing semantics of Smalltalk. Alan Kay, in turn had based the message passing semantics of Smalltalk on the goal-driven evaluation of PLANNER, which was designed by Carl Hewitt.

PLANNER was the precursor to Prolog. Erlang a language based on actor model where processes are actor was originally not intended to be a language, rather it started out as a library for fault-tolerant distributed programming in Prolog, and later evolved into a dialect of Prolog, before it became its own language, still to this day heavily influenced by Prolog.

So, the similarities between Objects in OO, and Actors in the Actor Model are far from coincidental.

Re: Actix – Actor Framework for Rust

#44

Post by EugeneOZ » Thu, Feb 13, 2020, 1:03 PM UTC

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.

You have no experience and arguing with someone who has experience. Very impressive.

Re: Actix – Actor Framework for Rust

#45

Post by undecisive » Thu, Feb 13, 2020, 1:06 PM UTC

_-___________-_ 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…

That seems a pretty balanced summary from my understanding of it.

One thing that I think should be noted: a lot has been said about this framing the original developer as unwilling. I'd say an unfair amount - from what I've seen, "cautiousness" would be a better description of his attitude, and hostility seems to have been shown when people blindly wade in ignoring all the discussion.

So for example, back in 2018, here he is publicly mulling it over: https://github.com/actix/actix-web/issues/289#issuecomment-3... and https://github.com/actix/actix-web/issues/289#issuecomment-3...

Here he is actively working to reduce the reliance on unsafe practices: https://github.com/actix/actix-web/issues/289#issuecomment-3...

Here he actively and very concisely points out his actual viewpoint: https://github.com/actix/actix-web/issues/289#issuecomment-3...

... and there are plenty of other examples in this and other tickets. Massive actions were taken by others and himself to significantly reduce the unsafe code where possible, and yet it seems the abuse kept coming.

I'd be interested to hear whether the new maintainer has had similar experiences. Unfortunately, our preferences in software development, often a product of a desire to generalise a specific overreaction, tend to become quasi-religious and puritanical. Members get outcast from their communities for trying to speak sense. I hope that this debacle will cause the community to mature, though I fear many will see it as a win and galvanise their viewpoint. We must remember that silver bullets can kill more than just werewolves.

Re: Actix – Actor Framework for Rust

#46

Post by DeedsMoraine » Thu, Feb 13, 2020, 1:06 PM UTC

Qwuke wrote: post #37

dragonsh wrote: post #35

Earlier quoted context omitted.

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.

I don't think the 'Rust is not as far along as backend web Haskell' is true in my (minimal) experience. I've worked at one very small company and one very large company, and at both Rust was a much more serious/common consideration for web services than Haskell.

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.

Re: Actix – Actor Framework for Rust

#47

Post by tlamponi » Thu, Feb 13, 2020, 1:07 PM UTC

jamil7 wrote: post #2

Whats the state of Rust if I wanted to get into it for backend development? I've looked briefly into Rocket and liked it but didn't delve too deep, I understand Actix is one of the most mature?

We do a new project in rust. It has a REST API building upon tokio and hyper, effectively the whole backend is in rust.

Building upon hyper isn't to bad, but not the "plug and play" way, I'd guess. For us it's OK, as we have a lot of control over the design and the stuff on top isn't to much.

Things are fast, code is OK once you wrangled about it with the compiler, async support is already OK (but definitively needs to improve, especially in the compiler for diagnostics and errors).

Re: Actix – Actor Framework for Rust

#48

Post by alecmg » Thu, Feb 13, 2020, 1:09 PM UTC

microtonal wrote: post #20

Isn0gud wrote: post #13

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

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

Re: Actix – Actor Framework for Rust

#49

Post by imtringued » Thu, Feb 13, 2020, 1:15 PM UTC

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?

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 semantically incompatible with OOP style method calls. Your methods will have to be written with the expectation that they are called multiple times or maybe not at all and most OOP code doesn't satisfy these expectations because the OOP model doesn't require it. If you extend the OOP model with message semantics of the actor model then what you get is not just OOP+messaging. It's the actor model.

Also you may have misunderstood something very fundamental. The benefit of paradigms isn't to be completely different. It's that everyone that shares a paradigm follows the same design philosophy. Imagine a mixed code base consisting of traditional OOP (with locks), actor model, async/await, promises. It would be very difficult to understand and sometimes it isn't obvious which of these is used. Some functions are asynchronous or they may fail but you may not know that because every single line could do a different thing. They may even be incompatible with each other. If you follow a single paradigm instead of many different ones you can avoid a lot of confusion and wasted work.

Re: Actix – Actor Framework for Rust

#50

Post by Qwuke » Thu, Feb 13, 2020, 1:16 PM UTC

DeedsMoraine wrote: post #46

Qwuke wrote: post #37

Earlier quoted context omitted.

I don't think the 'Rust is not as far along as backend web Haskell' is true in my (minimal) experience. I've worked at one very small company and one very large company, and at both Rust was a much more serious/common consideration for web services than Haskell.

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 projects I'd imagine they'd meet similar levels of resistance.