News for hackers. Stuff that matters.

A comment on The Piston image library is now pure Rust. Parent comment

Re:The Piston image library is now pure Rust by stymaar on Sunday January 08, 2017 @09:26AM (#13349780)
> As I mentioned in my other comment I'm also not sure what you mean by "concurrency primitives" here, from your mention of server-side programming it would appear that you want something that handles async I/O, but this comment seems to indicate otherwise, and Rust does have pretty nice primitives (in the stdlib, and in rayon/crossbeam) for general parallel programming.

Since he mention Go and Erlang, I think what the gp just wishes Rust had a built-in solution for M:N threading.

Whether M:N threading is nicer than async APIs is highly subjective though. (I'm talking about ergonomics here. I think it's widely accepted that async is more efficient when performance really matters)

[ Parent | on HN ]
Re:The Piston image library is now pure Rust by Manishearth on Sunday January 08, 2017 @09:32AM (#13349801)
> I think what the gp just wishes Rust had a built-in solution for M:N threading.

Yeah, but then they say that they doesn't want concurrency to be based on async io primitives, which is exactly what Go does IIRC.

[ Parent | on HN ]
Re:The Piston image library is now pure Rust by lobster_johnson on Monday January 09, 2017 @03:17AM (#13354820)
Both Go and Erlang are based on blocking, synchronous I/O primitives combined with asynchronous communication between the green threads that use them. It's a lot easier to reason about than event-based I/O.
[ Parent | on HN ]
Re:The Piston image library is now pure Rust by stymaar on Sunday January 08, 2017 @10:05AM (#13349921)
> which is exactly what Go does IIRC.

Under the hood, I guess yes. But in Go, the developer always use blocking API and the runtime does the magic with the async stuff. Some people find it easier to reason about code written this way.

[ Parent | on HN ]