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…
Actix – Actor Framework for Rust
31–40 of 129 posts
Re: Actix – Actor Framework for Rust
#32Earlier 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!
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
#33Earlier 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!
Re: Actix – Actor Framework for Rust
#34Can 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…
Re: Actix – Actor Framework for Rust
#35Earlier 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.
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
#36Earlier 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.
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
#37Earlier 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'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
#38Can 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.
Re: Actix – Actor Framework for Rust
#39What 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?
Re: Actix – Actor Framework for Rust
#40What 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.