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

111–120 of 125 posts

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

#111

Post by ejanus »

rkangel wrote: post #86
sudeepj wrote: post #57

> fn greet(req: HttpRequest) -> impl Responder Nice to see front page example using 'impl', the recent most improvement in ergonomics. Before 1.26 things would be different. This makes me more appreciative of the efforts from Rust team/community to improve the ease of use.

To explain this to people who don't know the background - this is about 'impl NameOfTrait' in the return position. It allows functions to return an object that provides a certain interface without specifying the actual type of that object. This was only previously true by wrapping it in a 'box', which meant a heap allocation and dynamic dispatch. The 'impl trait' provides static dispatch and no other overhead, so pro…

What is the use case ? Is there simple examples one could go through?

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

#112

Post by ejanus »

urschrei wrote: post #31
nevi-me wrote: post #15

I've had relatively good success moving some microservices from Kotlin to Rust (mainly saving about 90% resident memory util). I picked up Actix recently, and so far I'm enjoying using it. If Rust library support for geospatial tools was as good as turf.js, I'd be able to move a lot more stuff into Rust.

Turf development is funded by Mapbox. If you need more Geo functionality than that provided by https://github.com/georust/rust-geo (I'm one of the developers), contributions are actively encouraged, and we're happy to mentor people. Alternatively, feel free to pay for some dev time if you need something specific (e.g. OpenCage paid to have their geocoder included in https://github.com/georust/rust-geocoding , dual-li…

I would like to join so that I would be mentored . So, where do I start ?

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

#113

Post by e12e »

fafhrd91 wrote: post #19
infynyxx2 wrote: post #11

Browsing thru Actix guide ( https://actix.rs/actix/guide/ ), I didn't find any explanation regarding what will happen when actor(s) crashes or how crashes[1] are being handled? http://wiki.c2.com/?LetItCrash

first, you need to define what is crash in rust means. panic or error. in general case you can not recover from panic. in case of error, type system prevents unhanded errors in actors. you can restart actor, but that is controlled by developer action.

A panic in an actor will take down the whole (rust) server?

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

#114

Post by fafhrd91 »

e12e wrote: post #113
fafhrd91 wrote: post #19

Earlier quoted context omitted.

first, you need to define what is crash in rust means. panic or error. in general case you can not recover from panic. in case of error, type system prevents unhanded errors in actors. you can restart actor, but that is controlled by developer action.

A panic in an actor will take down the whole (rust) server?

one thread in best case. But process may die. Depends on panic

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

#115

Post by dbcfd »

steveklabnik wrote: post #110
dbcfd wrote: post #109

Earlier quoted context omitted.

I'm in the same boat, at least for actix-web. The static lifetimes on the handlers (and I think state) makes some things really painful, but is also part of the reason it gets the speed it does. The actix library is fairly nice though, but still a few cases where the use of globals and/or statics introduces problems.

We've got some stuff in the pipeline that should relax that requirement. It plus async/await (which has a PR open in the compiler) should make all of this way easier.

Good to hear. Could use box to get around the static stuff, but given the power of lifetimes, would much rather be able to use lifetimes correctly to not have to box everything.

One other thing that wasn't really apparent but would have made my life easier is a way to use an actor to handle a request, so I could have access to a context for thread related activities (e.g. tokio handles). It feels wrong to just use Arbiter::handle there, especially for testable code.

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

#116

Post by fulafel »

znfi wrote: post #78

Not sure if I'm missing something, but for the Techempower Bencharks [1] I had the impression that the bottleneck for other rust libraries were in accessing the database rather than handling http requests. However, looking at the code [2] it seems that the Actix solution isn't doing anything special with regards to this. Can someone give a quick description of "what" is causing such a huge performance boost for Actix…

If you are doing sql queries in web requests, you probably should not invest in Rust for performance.

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

#117

Post by zarvox »

MrBuddyCasino wrote: post #26
zarvox wrote: post #17

I've recently been building an IRC bouncer and webapp with Actix, and it's been really smooth sailing so far -- excellent documentation, extensive examples, and everything I've touched so far has just worked the way you'd expect it to. It's a gem of a project.

Wanted to do the same exact thing! Is it public?

Not yet (still incomplete) but I'd be happy to drop you a line if/when that changes - send me an email?

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

#118

Post by Jweb_Guru »

ccccccccccccc wrote: post #98

Question: What is the point of making the fastest web server possible when any kind of datastore attached to the server is going to be the bottleneck?

Many modern databases are very fast and many modern web servers are very slow. I've run into many applications where database performance was not the bottleneck.

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

#119

Post by iopq »

ejanus wrote: post #111
rkangel wrote: post #86

Earlier quoted context omitted.

To explain this to people who don't know the background - this is about 'impl NameOfTrait' in the return position. It allows functions to return an object that provides a certain interface without specifying the actual type of that object. This was only previously true by wrapping it in a 'box', which meant a heap allocation and dynamic dispatch. The 'impl trait' provides static dispatch and no other overhead, so pro…

What is the use case ? Is there simple examples one could go through?

Usually you return a closure with impl Fn. Another use case is to return an iterator.

I wrote a post about it. Let me know if it helps.

https://medium.com/@iopguy/impl-trait-in-rust-explanation-ef...

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

#120

Post by steveklabnik »

ejanus wrote: post #111
rkangel wrote: post #86

Earlier quoted context omitted.

To explain this to people who don't know the background - this is about 'impl NameOfTrait' in the return position. It allows functions to return an object that provides a certain interface without specifying the actual type of that object. This was only previously true by wrapping it in a 'box', which meant a heap allocation and dynamic dispatch. The 'impl trait' provides static dispatch and no other overhead, so pro…

What is the use case ? Is there simple examples one could go through?

https://blog.rust-lang.org/2018/05/10/Rust-1.26.html has a section about it.
Post reply on HN