Hacker News Reader

Comment by fafhrd91 | Hacker News Reader

tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark

https://www.techempower.com/benchmarks/#section=data-r15&hw=...

Ugh. Every time I see tokio or futures-rs mentioned, a part of me dies.

The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has a different type, even if they resolve to the same types upon evaluation of the future - basically abusing the type system to store the futures chain. Combined with the very strongly typed nature of rust, even with experimental language features like “impl future<xxx>” the code becomes impossibly hard to reason about.

For example, the result of future.or returning a future bool is not the same type as the result of future.and similarly returning a future bool; and a two-level future evaluating to a future bool is not the same type as a one-level future also evaluating to a future bool.

async/await cannot come soon enough.

I've never quite understood the benefits of async/await over go-style csp. It seems to me that its far better to just write sequential code all the time then mark all the points where you add parallelism with spawn/go instead of layer abstractions to approximate the same result but with added (in my view unneccesary) keywords. Can anyone provide some insight?

go-style csp is just async/await hidden in the syntax.

It's not, because it's not built on promises at all. Go uses separate stacks for every goroutine.

Async/await can be cheaper given other constraints, e.g. Go ends up using a lot of GC infrastructure to keep stacks small/minimize memory use, which makes FFI to C-style languages expensive.

If syntax is all that matters, then sequential code is great, but there's more than that for many tasks.

(In any case, Go is adding layers of abstraction too: it is exposing a sequential interface over the OS's async APIs, whereas async/await is typically exposing them more directly.)

With async/await you can tell from the type signature whether a given function might suspend, and then reading through the body you can see whether each function call is a non-suspending one or a possibly-suspending one. It makes it really obvious what's doing what. If suspension is your only effect then it probably doesn't matter (one unmanaged effect is ok), but when you have other effects that might interact, having all the suspension points be explicit is really useful. https://glyph.twistedmatrix.com/2014/02/unyielding.html gives one example.

Thanks, yeah, that's a useful insight. I guess it's rather a moot point with Go anyway since you have multiple goroutines executing on multiple cores at once.

There are technical benefits and drawbacks to both approaches.

I think the main reasons people perfer one over the other are philosophical: basically, some people prefer managing the executors of concurrent code (goroutines/threads/whatever); others prefer managing the points of dispatch to executors.

You can do both in either paradigm, but those are what I see as the default modes of thinking. Neither is inherently better; it just depends on how you personally think about concurrency, and what concurrent tasks you need to model.

Go has a lot of complexity and slowdown around FFI due to all the internal context switching, locking, and stack management. Even if there are benefits for this use case, for such a drawback is not acceptable for a systems language intended for embedding and low level libraries.

> some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has a different type, even if they resolve to the same types upon evaluation of the future - basically abusing the type system to store the futures chain

If you don't need the performance, you can get back to the dynamic-language world by boxing everything (.boxed()). The generics approach lets everything be compiled down to a single state machine, exactly like Iterator.

hyper is 6 and actix is 7

https://github.com/actix/actix-web

Rust is represented well!

I tried Actix a while back and it was very intimidating compared to some other frameworks. I'd like to jump back into it at some point, but right now for my prototype I got lazy and went with Rocket.rs.

Any suggestions of Opensource projects that use Actix?

you should check it again :) actix-web now has user guide https://actix.github.io/actix-web/guide/

here is irc bot (wip) https://github.com/DoumanAsh/roseline.rs

Is there a guide just for using the actix framework that explains what are actors, how they are different from other abstractions and the pros and cons?

There is no guide for actix but I am planing to add one

Ah, I didn't check your username. So, its your project, awesome work and thanks for doing it. :D

Thanks fafhrd!

I wouldn't post Rust benchmarks in here it's behind Java in every scenarios.

It's not in every scenario, notably, the plaintext one.

One reason why things are behind in some of the other scenarios is because our database driver stuff is synchronous at the moment, and that really hurts on these benchmarks. We'll get there!

stable rust is only two years old. we just need some more time

Performance is one dimension of many.

Maybe in web, but overall I don't think this is true [0]

[0]: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Which says more about Java than Rust. Despite all the "Java is slow" boohoo modern Java is a blazing fast language for many problems. Rust is young, still much potential.

Reply on news.ycombinator.com