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

41–50 of 66 posts

Re: 24 days of Rust – Rayon

#41

Post by saghm »

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 shared use-cases (and again, you'll likely find at least some shared use-cases if you pick any two languages). I feel like constantly bringing up Rust and Go together confuses things more than it helps, since they really aren't that similar.

Re: 24 days of Rust – Rayon

#42

Post by rogerdpack »

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…

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

Re: 24 days of Rust – Rayon

#43

Post by StevePerkins »

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 in the real world, one is really competing with Java and Python while the other is competing with C++. I don't even see Go and Rust as head-to-head competitors at all... and I definitely don't understand their uni-directional "feud" (i.e. nearly every Rust thread is has people taking shots at Go, yet most Go threads don't mention Rust at all).

Re: 24 days of Rust – Rayon

#44

Post by Manishearth »

lukaslalinsky wrote: post #17
kybernetikos wrote: post #14

Earlier quoted context omitted.

I know scala a bit and rust only barely, but they seem like very different languages to me. Scala tries to enable you to create whatever api you want, so it has many different flavours of magic to allow flexibility of expression. Predictably this is used and abused horribly by a community who can't come to a consensus on what good taste is. Rust on the other hand makes you explicitly say everything that happens. Noth…

> Nothing will happen without you being aware of it This is exactly the opposite what I understood from the article that Rayon does. For example, it will schedule your code differently depending on the current conditions of the CPU. That kind of non-determinism is hard to deal with if you are doing something more complex than adding numbers. I imagine this is fine for building mathematical libraries, where you care a…

> This is exactly the opposite what I understood from the article that Rayon does

You are aware of it. You put the par_iter() call there. Rust won't magically parallelize regular .iter() loops.

If you don't want to reason about parallelism, don't use Rayon. That's pretty explicit.

Re: 24 days of Rust – Rayon

#45

Post by Manishearth »

lukaslalinsky wrote: post #28
kibwen wrote: 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.

I have left more comments on this thread than I should considering my lack of experience with Rust, but I think the comparison with Scala is valid. What got me thinking about that was the implementation of into_par_iter, which is a trait implemented on a bunch of standard types, not unlike implicit methods in Scala. I know this is rare code, but reading this left with very similar feeling that I had when reading Scal…

Being able to extend other types with methods is a pretty common feature in many languages, many of which are much less magic than Scala. It's very common in functional languages with objects.

Re: 24 days of Rust – Rayon

#46

Post by im_down_w_otp »

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 experience the same thing all the time. Go has become the new node.js for ineffectual, out-of-touch technical managers and mediocre engineers to just randomly throw out as their "What about _____?" hobby horse.

I got myself out of the position of contrasting it against whatever they were railing against (in this case Erlang), and instead just put the question back on them. "I don't know, you tell me why I should consider Go for this."

Usually shuts down the conversation because they don't actually know anything about Go. Just that they've heard other people talk about it.

Re: 24 days of Rust – Rayon

#47

Post by im_down_w_otp »

kibwen wrote: post #24
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.

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.

What's described here is precisely how Rust and Erlang became my two favorite languages to work with.

Re: 24 days of Rust – Rayon

#48

Post by dispose13432 »

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…

>Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency.

Why can't Firefox tolerate garbage collection latency?

Re: 24 days of Rust – Rayon

#49

Post by steveklabnik »

dispose13432 wrote: post #48
StevePerkins wrote: post #43

Earlier quoted context omitted.

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…

>Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency. Why can't Firefox tolerate garbage collection latency?

Rendering webpages is a very intense task. Many of the improvements Servo is working on are basically "how can we transpose AAA video game technologies and techniques into web page rendering." The problems are more similar than you'd imagine.

Re: 24 days of Rust – Rayon

#50

Post by geoka9 »

tatterdemalion wrote: post #23
lukaslalinsky wrote: post #17

Earlier quoted context omitted.

> Nothing will happen without you being aware of it This is exactly the opposite what I understood from the article that Rayon does. For example, it will schedule your code differently depending on the current conditions of the CPU. That kind of non-determinism is hard to deal with if you are doing something more complex than adding numbers. I imagine this is fine for building mathematical libraries, where you care a…

This makes no sense to me. You are absolutely aware this will happen because you called Rayon's `.par_iter()` method! The pitfalls of parallel and concurrent computing are well known, and you are correct should not use a data parallelism library for effectful actions whose order matters. But of course the same concerns can arise when using goroutines. In contrast, Rust actually does guarantee an absence of data races…

I know it's not the same, but in Go you can compile with `-race` and it'll catch race conditions at run-time (useful for testing/debugging).
Post reply on HN