Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

24 days of Rust – Rayon

siciarz.net

Post reply on HN
Print view View original

51–60 of 66 posts

Re: 24 days of Rust – Rayon

#51

Post by iamed2 »

saghm wrote: post #41
lukaslalinsky wrote: post #4

I have not done any real programming in Rust, but whenever I see Rust code I'm amazed how different is it from Go, despite both having some shared use cases. Go's main selling point beyond concurrency is simplicity. And it's the simplicity that I like about it. On the other hand, it looks to me like Rust is turning into Scala.

Because I'm one of the only people passionate about Rust at my job (and there are plenty who love Go), I'm often asked questions about Rust vs. Go, which actually perplexes me a little. Asking "What about Go?" when someone brings up Rust is essentially like saying "What about OCaml?"; the languages have a few similar features (as most languages do, IMO), but they have completely different goals and only a subset of s…

I think people compare them because they were both designed as alternatives to C++ (or at least with that in mind). What people might miss is that they were solving two very different problems: Rust aims to be as fast (or faster) while guaranteeing memory safety, while Go aims to be easy to understand and get productive as quickly as possible.

Re: 24 days of Rust – Rayon

#52

Post by pcwalton »

jMyles wrote: post #31
pcwalton wrote: post #2

Rayon is definitely the best parallelism library I've ever used. We recently switched Servo over to using it for parallel restyling and layout and saw small gains in performance over our previous solution and drastic reduction in code complexity (and removed a whole pile of domain-specific unsafe code). Being able to switch .iter() to .par_iter() and have things "just work" is a game changer. The crucial thing about…

> Rayon is definitely the best parallelism library I've ever used. Whenever people say this, I ask the following question in order to gauge whether I want to try the library in question: Have you used Twisted? Twisted is, to me, the quintessential example of a high-quality open source project. If you have used it extensively and still recommend Rayon, I'll give it a try.

Twisted is not for parallelism. Twisted is for concurrency.

Re: 24 days of Rust – Rayon

#53

Post by jordwest »

anp wrote: post #6
lukaslalinsky wrote: post #4

I have not done any real programming in Rust, but whenever I see Rust code I'm amazed how different is it from Go, despite both having some shared use cases. Go's main selling point beyond concurrency is simplicity. And it's the simplicity that I like about it. On the other hand, it looks to me like Rust is turning into Scala.

My personal experience with Rust (vs. Go and other languages) is that there is something really magical that all the sigils and syntactic complexity give you: once you've internalized Rust's approach it's ridiculously easy to build an accurate mental model of what's happening in almost any piece of code. From the high level constructs down to generated assembly, Rust produces the most predictable code I've ever writt…

I'm still in the early days of learning Rust, but from what I've seen so far I agree with that feeling of having a better mental model of the program. At first the language and syntax seemed overwhelming, but slowly its all coming together and what I thought was verbose syntax turns out to be incredibly helpful in terms of forcing me to think things through.

Several times now when caught out by the borrow checker, I've wondered, wow, how do other languages get away with allowing a situation like this.

This video series by the author of Rayon (and Rust core dev) was what first hooked me and made the syntax a lot more understandable: http://intorust.com/

Re: 24 days of Rust – Rayon

#54

Post by rat87 »

StevePerkins wrote: post #43
lukaslalinsky wrote: post #4

I have not done any real programming in Rust, but whenever I see Rust code I'm amazed how different is it from Go, despite both having some shared use cases. Go's main selling point beyond concurrency is simplicity. And it's the simplicity that I like about it. On the other hand, it looks to me like Rust is turning into Scala.

Are there really a lot of "shared use cases" between Rust and Go? I realize that Go's creators intended for it to be a systems language. In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world. Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency. Of course they're both general-purpose languages in theory. But i…

> In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world.

I don't know about microservices but I think it could compete for command-line devops apps.

Re: 24 days of Rust – Rayon

#55

Post by alkonaut »

lukaslalinsky wrote: post #4

I have not done any real programming in Rust, but whenever I see Rust code I'm amazed how different is it from Go, despite both having some shared use cases. Go's main selling point beyond concurrency is simplicity. And it's the simplicity that I like about it. On the other hand, it looks to me like Rust is turning into Scala.

My main problem with rust at this point is the noise caused by a lot of the wrangling of standard types.

I know it's a low-ish level language that leaves a lot explicit for the developer to type, and that a lot of boilerplate things could yet be turned into conventions or macros much like try!, as the language matures.

I'd really like to see this process accelerate as a lot of Rust code now is littered with into(), unwrap() etc. which causes mental overhead for the reader.

I'd like to see more "zero cost abstractions" where the zero also includes zero characters typed that aren't part of the problem itself. As a benchmark, I'd like to see "noise parity" with go/ocaml/swift while still having the nice safety/performance Rust has today.

Re: 24 days of Rust – Rayon

#56

Post by the8472 »

pcwalton wrote: post #2

Rayon is definitely the best parallelism library I've ever used. We recently switched Servo over to using it for parallel restyling and layout and saw small gains in performance over our previous solution and drastic reduction in code complexity (and removed a whole pile of domain-specific unsafe code). Being able to switch .iter() to .par_iter() and have things "just work" is a game changer. The crucial thing about…

I have played around a tiny bit with par_iter over blocking IO tasks and seen some sched_yield() loops burning CPU time instead of backing off to futex_wait. That seems suboptimal and not exactly "the best ever" I'd expect from a parallelism library.

Re: 24 days of Rust – Rayon

#57

Post by p0nce »

pcwalton wrote: post #2

Rayon is definitely the best parallelism library I've ever used. We recently switched Servo over to using it for parallel restyling and layout and saw small gains in performance over our previous solution and drastic reduction in code complexity (and removed a whole pile of domain-specific unsafe code). Being able to switch .iter() to .par_iter() and have things "just work" is a game changer. The crucial thing about…

> Being able to switch .iter() to .par_iter() and have things "just work" is a game changer.

It's called .parallel() in D, works the same way I guess. It turns a lazy computation chain into a parallel one.

Re: 24 days of Rust – Rayon

#58

Post by pcwalton »

the8472 wrote: post #56
pcwalton wrote: post #2

Rayon is definitely the best parallelism library I've ever used. We recently switched Servo over to using it for parallel restyling and layout and saw small gains in performance over our previous solution and drastic reduction in code complexity (and removed a whole pile of domain-specific unsafe code). Being able to switch .iter() to .par_iter() and have things "just work" is a game changer. The crucial thing about…

I have played around a tiny bit with par_iter over blocking IO tasks and seen some sched_yield() loops burning CPU time instead of backing off to futex_wait. That seems suboptimal and not exactly "the best ever" I'd expect from a parallelism library.

They should be doing that for a few iterations before backing off. Otherwise you end up with bad scheduling leading to slow warmups, among other problems.

You shouldn't use rayon for blocking I/O; that's not what it's designed for. Rayon is a parallelism library, not a concurrency library.

Re: 24 days of Rust – Rayon

#59

Post by kazagistar »

rogerdpack wrote: post #42
anp wrote: post #6

Earlier quoted context omitted.

My personal experience with Rust (vs. Go and other languages) is that there is something really magical that all the sigils and syntactic complexity give you: once you've internalized Rust's approach it's ridiculously easy to build an accurate mental model of what's happening in almost any piece of code. From the high level constructs down to generated assembly, Rust produces the most predictable code I've ever writt…

What about maintainability here, how would you rate it vs. (go, python, etc.)? I.e. coming into a new code base, etc?

I'm neither the OP nor a Rust expert, but I have found it quite easy to jump into and read/tweak both an established expert's code base and a new learner's code base.

Compared to Python: Rust is certainly a bit more verbose, due to being much more careful with performance, memory and precise types. But I find that the last one actually makes Rust easier to maintain. In Rust, I just have to look at the types being passes around, while in a complex Python code base, I might ask PyCharm for all calls to a function and work backwards, slowly try to infer what kind of thing a variable might be.

Go is much closer to Rust in terms of maintainability, but I haven't worked with it enough to say, because I didn't like other aspects of the language.

Re: 24 days of Rust – Rayon

#60

Post by [deleted] »

StevePerkins wrote: post #43
lukaslalinsky wrote: post #4

I have not done any real programming in Rust, but whenever I see Rust code I'm amazed how different is it from Go, despite both having some shared use cases. Go's main selling point beyond concurrency is simplicity. And it's the simplicity that I like about it. On the other hand, it looks to me like Rust is turning into Scala.

Are there really a lot of "shared use cases" between Rust and Go? I realize that Go's creators intended for it to be a systems language. In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world. Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency. Of course they're both general-purpose languages in theory. But i…

[deleted]
Post reply on HN