News for hackers. Stuff that matters.
Re:Rust 1.24 by fafhrd91 on Thursday February 15, 2018 @04:34PM (#16387866)
tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark

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

Re:Rust 1.24 by ComputerGuru on Friday February 16, 2018 @05:02AM (#16391217)
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.

Re:Rust 1.24 by RX14 on Friday February 16, 2018 @07:02AM (#16391708)
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?
Re:Rust 1.24 by lmm on Friday February 16, 2018 @07:27AM (#16391824)
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.
Re:Rust 1.24 by RX14 on Friday February 16, 2018 @08:03AM (#16392008)
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.
Re:Rust 1.24 by zbentley on Friday February 16, 2018 @10:04AM (#16392790)
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.

Re:Rust 1.24 by dbaupp on Friday February 16, 2018 @07:18AM (#16391770)
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.)

Re:Rust 1.24 by kazagistar on Friday February 16, 2018 @10:25AM (#16392947)
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.
Re:Rust 1.24 by 62747478182 on Friday February 16, 2018 @07:13AM (#16391753)
go-style csp is just async/await hidden in the syntax.
Re:Rust 1.24 by RX14 on Friday February 16, 2018 @07:53AM (#16391962)
It's not, because it's not built on promises at all. Go uses separate stacks for every goroutine.
Re:Rust 1.24 by dbaupp on Friday February 16, 2018 @07:20AM (#16391784)
> 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.

Re:Rust 1.24 by fafhrd91 on Thursday February 15, 2018 @04:35PM (#16387881)
hyper is 6 and actix is 7

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

Rust is represented well!

Re:Rust 1.24 by jrhurst on Thursday February 15, 2018 @07:07PM (#16388905)
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?

Re:Rust 1.24 by fafhrd91 on Thursday February 15, 2018 @08:01PM (#16389143)
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

Re:Rust 1.24 by todd_wanna_code on Thursday February 15, 2018 @11:22PM (#16389841)
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?
Re:Rust 1.24 by fafhrd91 on Friday February 16, 2018 @12:27AM (#16390091)
There is no guide for actix but I am planing to add one
Re:Rust 1.24 by todd_wanna_code on Friday February 16, 2018 @12:31AM (#16390118)
Ah, I didn't check your username. So, its your project, awesome work and thanks for doing it. :D
Re:Rust 1.24 by jrhurst on Monday February 19, 2018 @01:17PM (#16414538)
Thanks fafhrd!
Re:Rust 1.24 by Thaxll on Thursday February 15, 2018 @07:44PM (#16389065)
I wouldn't post Rust benchmarks in here it's behind Java in every scenarios.
Re:Rust 1.24 by steveklabnik on Thursday February 15, 2018 @07:50PM (#16389097)
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!

Re:Rust 1.24 by thsowers on Thursday February 15, 2018 @09:23PM (#16389425)
Maybe in web, but overall I don't think this is true [0]

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

Re:Rust 1.24 by sgift on Friday February 16, 2018 @07:04AM (#16391715)
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.
Re:Rust 1.24 by fafhrd91 on Thursday February 15, 2018 @08:03PM (#16389157)
stable rust is only two years old. we just need some more time
Re:Rust 1.24 by nerpderp83 on Thursday February 15, 2018 @08:32PM (#16389264)
Performance is one dimension of many.