Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Actix: a small, pragmatic, and fast Rust web framework

actix.rs

Post reply on HN
Print view View original

41–50 of 125 posts

Re: Actix: a small, pragmatic, and fast Rust web framework

#41

Post by empath75 »

reacharavindh wrote: post #40
sondr3 wrote: post #37

Earlier quoted context omitted.

5MB is nothing compared to what you'd use for a similar project in node or Python or Ruby. Sure, it's not the tiniest it could be, but using tools like strip, not including debug symbols etc it gets pretty damn small. Honestly though, at that point I think size becomes entirely pointless to even mention unless you need to run it in a super constrained environment, which you're probably not when you're using the stand…

Yes, I'm not constrained in any way to not be able to run a 5 MB binary. I was curious if that was an indication of what is to come for large projects... I guess I was tangentially pointing to complexity and abstraction there.

rust doesn't use dynamic linking, which contributes a lot to that size.

Re: Actix: a small, pragmatic, and fast Rust web framework

#43

Post by jdright »

tormeh wrote: post #28
jsandler18 wrote: post #23

I tried using actix for a recent project. I just could not get it to do what I wanted to. It always felt like a fight. I switched to rocket and everything is so much easier. Everyone is saying great things about it, but I just want to point out that it's not for everyone.

Don't know anything about Actix, but can confirm that Rocket is excellent. The actor abstraction is very interesting, though. Anyone have any insight into how Actix and Rocket compare? I'm interested mostly in ergonomics and safety.

I've done a simple hobby project in Rocket and ported to Actix.

I'm not experienced with web services and my project was very limited for learning purposes, here my take away:

I like both and for me Rocket was way more ergonomic for creating routes dealing as if they're simple functions where input and output are dealt automatically with (from request and to response).

Actix advantage is actors and is easy to be fully async, I had some issues dealing with it but most of my troubles were extracting request data and building responses.

When actix-web will support magic as Rocket (once proc-macros becomes stable) then actix-web will have the edge if Rocket don't become async-ready and stable before.

For both it is only question of missing stable rust features and actix-web is already running on stable.

actix-web: - easy - async - stable

Rocket: - stupidly easy - sync - nightly

Re: Actix: a small, pragmatic, and fast Rust web framework

#45

Post by topspin »

stusmall wrote: post #5

What a great looking site. I've been really exciting about actix for a while now. We just started some internal experiments with it here and I'm looking forward to more.

Agreed. Good site.

This is an aside, and I sincerely apologize for that, but I am compelled...

I'm reading the greeting/hello-world example on this nice site and I notice unwrap_or(). That is a poor name: can it panic, as suggested by the "unwrap" part (I have just enough Rust to know that,) or can it not, as suggested by the "or" part? The name is inherently ambiguous!

It's as if the .unwrap() that is festooned throughout such example Rust code has become so ubiquitous that someone felt it had to be used and so tacked on "_or". Why couldn't it just be .or() or perhaps .default()?

And so I investigate and things go rapidly downhill from there. Consider:

    unwrap
    unwrap_or
    unwrap_or_else
    unwrap_or_default
    or
    or_else
Good grief. The word ambiguous seems inadequate to describe what has emerged here.

Again I'm sorry; this is clearly off topic, probably badly naive and possibly inappropriate in a few other ways to which I'm pathetically oblivious. I couldn't help myself.

Re: Actix: a small, pragmatic, and fast Rust web framework

#46

Post by Seanny123 »

jsandler18 wrote: post #23

I tried using actix for a recent project. I just could not get it to do what I wanted to. It always felt like a fight. I switched to rocket and everything is so much easier. Everyone is saying great things about it, but I just want to point out that it's not for everyone.

Interestingly, there is a proposal for Actix to be the HTTP layer of Rocket. https://github.com/SergioBenitez/Rocket/issues/17#issuecomme...

Re: Actix: a small, pragmatic, and fast Rust web framework

#47

Post by steveklabnik »

topspin wrote: post #45
stusmall wrote: post #5

What a great looking site. I've been really exciting about actix for a while now. We just started some internal experiments with it here and I'm looking forward to more.

Agreed. Good site. This is an aside, and I sincerely apologize for that, but I am compelled... I'm reading the greeting/hello-world example on this nice site and I notice unwrap_or(). That is a poor name: can it panic, as suggested by the "unwrap" part (I have just enough Rust to know that,) or can it not, as suggested by the "or" part? The name is inherently ambiguous! It's as if the .unwrap() that is festooned thro…

"unwrap" doesn't mean "panic". It means "to take out of some kind of container". So, the question is, what to do if the thing isn't in the container?

    unwrap: panic
    unwrap_or: produce this value instead
    unwrap_or_else: produce a value by running this closure instead
    unwrap_or_default: produce a default value instead
or and or_else are just like unwrap_or and unwrap_or_else, but they don't do the unwrapping; you keep the container.

In this case, the "container" is option, but similar types have the same methods, like Result.

> Why couldn't it just be .or() or perhaps .default()?

or returns Option, unwrap_or returns T. .default returns the default value for a T already.

TL;DR: you have a lot of options (pun intended, sorry!) with what to do, but the names all follow a quite regular scheme.

Re: Actix: a small, pragmatic, and fast Rust web framework

#48

Post by nnutter »

jsandler18 wrote: post #23

I tried using actix for a recent project. I just could not get it to do what I wanted to. It always felt like a fight. I switched to rocket and everything is so much easier. Everyone is saying great things about it, but I just want to point out that it's not for everyone.

Doesn’t Rocket dependend on nightly Rust? Doesn’t it use features that may never make it into stable Rust?

Re: Actix: a small, pragmatic, and fast Rust web framework

#49

Post by nobleach »

jsandler18 wrote: post #23

I tried using actix for a recent project. I just could not get it to do what I wanted to. It always felt like a fight. I switched to rocket and everything is so much easier. Everyone is saying great things about it, but I just want to point out that it's not for everyone.

I had the opposite experience. I wrote an endpoint in 3 languages/frameworks last weekend: Java/Spring Boot, Elixir/Phoenix, and Rust/Rocket. (the last was mostly going off this blog post: https://lankydanblog.com/2018/05/20/creating-a-rusty-rocket-...) I was fighting with Rust Nightly failing to compile a couple different packages. All the GitHub issues seemed to point to finding the magical combination that would make things run. I gave up after an hour or so. I'd like to have something that runs on Rust Stable. Rocket was pretty cool _looking_ though.

Actix-web was almost a drop-in replacement.

Re: Actix: a small, pragmatic, and fast Rust web framework

#50

Post by chewbacha »

I recently ported a very small micro service from Rocket to Actix and found the migration to be painless. In fact, it's use of types and inferencing along with integration with Serde made it very easy. It also worked on stable-rust and can work with connection pooling against postgres. This makes it a winner in my mind.

I'm excited to use it again in my next service.

Post reply on HN