Live data from Hacker News

24 days of Rust – Rayon

siciarz.net

31–40 of 66 posts

Re: 24 days of Rust – Rayon

#31
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.

Re: 24 days of Rust – Rayon

#32
post #31
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.

Assuming you're talking about the python library, it is more going for asynchronous IO and other more "concurrency" things than the data parallelism that rayon is designed for.

Re: 24 days of Rust – Rayon

#33
post #31
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.

[deleted]

Re: 24 days of Rust – Rayon

#34
post #32
post #31

Earlier quoted context omitted.

> 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.

Assuming you're talking about the python library, it is more going for asynchronous IO and other more "concurrency" things than the data parallelism that rayon is designed for.

Yeah, twisted is closer to tokio than rayon.

Re: 24 days of Rust – Rayon

#35

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.

[deleted]

Re: 24 days of Rust – Rayon

#36
post #32

Earlier quoted context omitted.

Assuming you're talking about the python library, it is more going for asynchronous IO and other more "concurrency" things than the data parallelism that rayon is designed for.

Yeah, twisted is closer to tokio than rayon.

Hey Steve. We met at TwilioCon 2011 - not sure if you remember that. How have you been?

Is there a good guide for someone in my position? ie, to learn about tokio and rayon, having used python (for, in this case, concurrency and data science respectively)?

Are you mostly using Rust these days?

Re: 24 days of Rust – Rayon

#37
post #36

Earlier quoted context omitted.

Yeah, twisted is closer to tokio than rayon.

Hey Steve. We met at TwilioCon 2011 - not sure if you remember that. How have you been? Is there a good guide for someone in my position? ie, to learn about tokio and rayon, having used python (for, in this case, concurrency and data science respectively)? Are you mostly using Rust these days?

Oh hey! That was a very long time ago, but I loved TwilioCon. Things are good. I'm actually working on Rust full-time, so yeah, I use it a lot. :)

I'm not sure there's a great guide yet, because a lot of this stuff is still shaking out. The Rust ecosystem in general is growing at a pretty steady clip, and new stuff pops up all the time: tokio is less than a year old, for example.

There's two different kinds of problems here: "I found a library, what does it do?" and "What libraries exist?" In the former case, you're at the mercy of the library author to give you a good description. With the latter, one of the better ways is to drop by #rust on IRC, or post to users.rust-lang.org, asking for an overview of what exists. https://crates.io/search is also helpful.

In this case, rayon is for "data parallelism", meaning "I have some data, I would like to do some work on it, and I'd like to make that paralell." Tokio is about asynchronous I/O.

Re: 24 days of Rust – Rayon

#38
post #26
post #12

Earlier quoted context omitted.

The problem with people referring to more or less simple mental models, syntax, learning curves, expressiveness, etc is that they usually only focus on one of those at a time, when it requires multiple of them to get a good picture of how a language will work in practice for you, and in general. As an extremely simple example of this, compare BASIC and APL in terms of the learning curve. If we examine it in isolation…

I would compare Rust to Python rather than Perl. Like Python, Rust tries to have only one obvious way to do things, and avoiding TIMTOWTDI is a conscious goal.

I wasn't actually comparing Rust to either, I was using the common comparison of Perl to Python to illustrate the point. Perl is often denigrated for being hard to read, but I maintain that for the most part that's a function of experience with the language (learning curve). After you've internalized a few things, I think Perl is easier to read in many cases, because the sigils, which people often complain about, actually convey additional information in a succinct and recognizable way once you learn to read them correctly. It's what you get from having a steeper (or actually, longer, not really steeper) learning curve. But that's still not the full picture, as you've alluded to with TIMTOWDI, which is yet another spectrum on which languages can be compared.

Re: 24 days of Rust – Rayon

#39
post #24

Earlier quoted context omitted.

If one were to have experience in both Rust and Scala, they would see that the comparison between the two is flawed. Scala revels in implicitness, whereas Rust is very explicit. Scala also has expressiveness as a goal, whereas in Rust expressiveness is an anti-goal. There are no user-defined operators in Rust, and less magic than in any language that I've used other than C.

> whereas in Rust expressiveness is an anti-goal. I think this is seriously over-stating it. We don't want Rust to be ugly or hard to use.

Yes this is true. I do wish I could have custom operators every now and then though, but that's a whole other bag of complexity and can be ugly if you don't know what each operator means.

Re: 24 days of Rust – Rayon

#40

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.

From the starting point of being a professional Java developer and a hobbyist Haskeller, Scala should've been the perfect language for me, yet I struggle with making it past just how complicated the language is -- not really complex, as such, just over-engineered.

To me, Rust feels like the simplest possible language that could achieve their design goals, whereas Go feels like they went so far out of their way to make it simple that they lost track of the other goals altogether.

Post reply on HN