Live data from Hacker News

Actix – Actor Framework for Rust

github.com

31–40 of 129 posts

Re: Actix – Actor Framework for Rust

#31
post #24
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've used Rocket and Actix for production web services. I love Rocket's conciseness; however, it still has a nightly dependency, and is still in the process of updating to async. If you can live without those two things, I'd highly recommend rocket. Actix is one of the most mature but (in my opinion) complicated for someone to stand up when just standing up a simple web service. It's extremely performant though. I'd…

FWIF I have played a bit with Actix for a few small projects, and it wasn't for me. It's a very "battery's included" library which does a lot of things for you, like transforming data structures into responses automagically. It feels a bit like rails where you just have to know the magic words sometimes to make things happen, and it's not exactly clear how things work.

Re: Actix – Actor Framework for Rust

#32

Earlier quoted context omitted.

Actix smashes a lot of benchmarks. For the regular dev/company in production use have no idea why people would use it. Hyper seems the sane option for most trying to simply build a backend. It's really good to see others building on it though. Won't deny how clunky it once was before async got stabilized.

You have to adjust the filters, because hyper isn't considered a "framework", but the TechEmpower benchmarks show hyper beating even actix (though it's narrow). Definitely agree things were pretty clunky for async Rust web stuff before async/await!

The sugar is real nice with async/await, plus some performance improvements. I got all excited upon release and moved my backend over to async, do somewhat regret not waiting 6 months.

Docs are sparse, this is across all the various crates needed, a bunch of required interoperable parts all needing specific alpha versions or separate preview crates.

Can't deny it's not user friendly right now. Very much early days.

Regardless, a lot of effort was put into the design and have to respect core devs for that. Think it was the most discussed/debated feature ever.

Re: Actix – Actor Framework for Rust

#33

Earlier quoted context omitted.

Actix smashes a lot of benchmarks. For the regular dev/company in production use have no idea why people would use it. Hyper seems the sane option for most trying to simply build a backend. It's really good to see others building on it though. Won't deny how clunky it once was before async got stabilized.

You have to adjust the filters, because hyper isn't considered a "framework", but the TechEmpower benchmarks show hyper beating even actix (though it's narrow). Definitely agree things were pretty clunky for async Rust web stuff before async/await!

Async-await is a game changer for all async rust development. Futures combinators became a sunk cost. Good riddance.

Re: Actix – Actor Framework for Rust

#34
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…

Your description is accurate and fair

Re: Actix – Actor Framework for Rust

#35
post #7

Earlier quoted context omitted.

At present Rust's primary focus is systems programming language, it will take another 3-5 years to be a viable web programming that too in a niche area. I doubt the libraries will be mature enough to provide easy way to build the way other languages do. If you know Ruby or Python or C# or Swift or Go language or Dart or TypeScript or JavaScript don't change to Rust yet. It's far far away from having similar library,…

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.

Re: Actix – Actor Framework for Rust

#36
post #31
post #24

Earlier quoted context omitted.

I've used Rocket and Actix for production web services. I love Rocket's conciseness; however, it still has a nightly dependency, and is still in the process of updating to async. If you can live without those two things, I'd highly recommend rocket. Actix is one of the most mature but (in my opinion) complicated for someone to stand up when just standing up a simple web service. It's extremely performant though. I'd…

FWIF I have played a bit with Actix for a few small projects, and it wasn't for me. It's a very "battery's included" library which does a lot of things for you, like transforming data structures into responses automagically. It feels a bit like rails where you just have to know the magic words sometimes to make things happen, and it's not exactly clear how things work.

I think that's a great description! Every 'batteries included' Rust web framework I've used so far makes the same boilerplate/magic trade off as Rails, though some magic has felt more intuitive than others.

Hyper doesn't remove much boilerplate but it's one of the most intuitive options that I've seen.

Re: Actix – Actor Framework for Rust

#37

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.

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.

Re: Actix – Actor Framework for Rust

#38
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 liked this summary https://youtu.be/enLUX1TtNyE

Re: Actix – Actor Framework for Rust

#39
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 other replies have covered this pretty well, but the two models are quite similar. The big difference is the formal constraints of the actor model, which allow people to build robust distributed systems. This is because the lack of certainty of communication and architecture is assumed as a first principle. This makes a big difference, in practice, for what programs actually look like.

Re: Actix – Actor Framework for Rust

#40
post #13
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.

Actually I think building oop on top of actor model makes the mental model far easier. Instead of worrying if the knight object uses the sword object to hurt the monster obect then which object .deals_damage? Or should the object take_damage? The actor framework, being all message passing, makes these choices clear. True, originally oop was message passing, but no mainstream modern oop languages except Ruby sorta are message passing frameworks.
Post reply on HN