4 ms·

tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintex

tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r15&hw=...

fafhrd91 9y ago
hyper is 6 and actix is 7 https://github.com/actix/actix-web https://github.com/actix/actix-web Rust is represented well!
- jrhurst 9y ago
  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?
  - fafhrd91 9y ago
    you should check it again :) actix-web now has user guide https://actix.github.io/actix-web/guide/ https://actix.github.io/actix-web/guide/ here is irc bot (wip) https://github.com/DoumanAsh/roseline.rs https://github.com/DoumanAsh/roseline.rs
    - todd_wanna_code 9y ago
      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?
      - fafhrd91 9y ago
        There is no guide for actix but I am planing to add one
        todd_wanna_code 9y ago
        Ah, I didn't check your username. So, its your project, awesome work and thanks for doing it. :D
    - jrhurst 9y ago
      Thanks fafhrd!
Thaxll 9y ago
I wouldn't post Rust benchmarks in here it's behind Java in every scenarios.
- steveklabnik 9y ago
  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!
- fafhrd91 9y ago
  stable rust is only two years old. we just need some more time
- nerpderp83 9y ago
  Performance is one dimension of many.
- thsowers 9y ago
  Maybe in web, but overall I don't think this is true [0] [0]: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=java https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
- sgift 9y ago
  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.
ComputerGuru 9y ago
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.
- RX14 9y ago
  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?
  - 62747478182 9y ago
    go-style csp is just async/await hidden in the syntax.
    - RX14 9y ago
      It's not, because it's not built on promises at all. Go uses separate stacks for every goroutine.
  - dbaupp 9y ago
    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.)

fafhrd91 9y ago

hyper is 6 and actix is 7 https://github.com/actix/actix-web https://github.com/actix/actix-web Rust is represented well!

jrhurst 9y ago
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?
- fafhrd91 9y ago
  you should check it again :) actix-web now has user guide https://actix.github.io/actix-web/guide/ https://actix.github.io/actix-web/guide/ here is irc bot (wip) https://github.com/DoumanAsh/roseline.rs https://github.com/DoumanAsh/roseline.rs
  - todd_wanna_code 9y ago
    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?
    - fafhrd91 9y ago
      There is no guide for actix but I am planing to add one
      - todd_wanna_code 9y ago
        Ah, I didn't check your username. So, its your project, awesome work and thanks for doing it. :D
  - jrhurst 9y ago
    Thanks fafhrd!

Thaxll 9y ago

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

steveklabnik 9y ago
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!
fafhrd91 9y ago
stable rust is only two years old. we just need some more time
nerpderp83 9y ago
Performance is one dimension of many.
thsowers 9y ago
Maybe in web, but overall I don't think this is true [0] [0]: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=java https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
sgift 9y ago
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.

ComputerGuru 9y ago

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.

RX14 9y ago
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?
- 62747478182 9y ago
  go-style csp is just async/await hidden in the syntax.
  - RX14 9y ago
    It's not, because it's not built on promises at all. Go uses separate stacks for every goroutine.
- dbaupp 9y ago
  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.)