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

11–20 of 66 posts

Re: 24 days of Rust – Rayon

#11

Post by lukaslalinsky »

pcwalton wrote: post #9
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.

How would you write rayon in Go? Can you describe the simpler signature of par_iter() that would work in Go? Can you describe the Go features that allow the compiler to prevent data races at compile time?

The answer to the questions is that you wouldn't do that in Go. Go doesn't have features that would allow you to do something like this efficiently. You are pretty much limited by the language. You can do high-level abstractions, not something low-level like this and I think that's where the simplicity comes from.

Re: 24 days of Rust – Rayon

#12

Post by kbenson »

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…

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, BASIC is obviously better. But if we use multiple criteria, the answer becomes much more nuanced, as we can see what the steeper learning curve allows. For a less extreme, but still ultimately the same comparison, imagine Perl and Python, or Go and Rust. A simple mental model is important, but if one choice is less simple, the question should really be what are you getting in return, and is the trade-off worth it? Otherwise, you should just program in BASIC and be done it it.

Re: 24 days of Rust – Rayon

#13

Post by derkha »

lukaslalinsky wrote: post #11
pcwalton wrote: post #9

Earlier quoted context omitted.

How would you write rayon in Go? Can you describe the simpler signature of par_iter() that would work in Go? Can you describe the Go features that allow the compiler to prevent data races at compile time?

The answer to the questions is that you wouldn't do that in Go. Go doesn't have features that would allow you to do something like this efficiently. You are pretty much limited by the language. You can do high-level abstractions, not something low-level like this and I think that's where the simplicity comes from.

What would that abstraction look like? I really can't think of a more high-level abstraction of parallelism than a single method call saying "Please parallelize this sequential algorithm. But only when it makes sense."

Re: 24 days of Rust – Rayon

#14

Post by kybernetikos »

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.

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. Nothing will happen without you being aware of it, and that makes it wordy and feel more complex, but it's the kind of complexity of having to say everything you mean down to a much greater level of detail rather than the kind of complexity that arises when it's almost impossible to know exactly what is going on.

Rust and Scala are pretty much at opposite ends of the 'magic' spectrum.

Re: 24 days of Rust – Rayon

#15

Post by virtualwhys »

derkha wrote: post #8
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.

What do you mean by "turning into"? I don't see much special syntax in the post apart from the general expression-oriented functional style, including higher-order functions. Which has always been part of Rust. If that means turning into Scala, then almost every high-level programming language is currently turning into Scala.

> If that means turning into Scala, then almost every high-level programming language is currently turning into Scala.

Martin Odersky, the creator of Scala, has said as much. Just look at Kotlin, Swift, and to some degree OCaml (upcoming modular implicits) and C# 7. Even Java 9 adopts Scala syntax with underscore now reserved.

Rust is its own thing, however. OP is probably referring to complexity of syntax that more powerful languages present to new comers.

Re: 24 days of Rust – Rayon

#16

Post by pcwalton »

lukaslalinsky wrote: post #11
pcwalton wrote: post #9

Earlier quoted context omitted.

How would you write rayon in Go? Can you describe the simpler signature of par_iter() that would work in Go? Can you describe the Go features that allow the compiler to prevent data races at compile time?

The answer to the questions is that you wouldn't do that in Go. Go doesn't have features that would allow you to do something like this efficiently. You are pretty much limited by the language. You can do high-level abstractions, not something low-level like this and I think that's where the simplicity comes from.

How does not being able to write the high-level par_iter() abstraction make Golang more high-level?

Re: 24 days of Rust – Rayon

#17

Post by lukaslalinsky »

kybernetikos wrote: post #14
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.

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 about the result, not about the order of operations. But if you are interacting with external APIs, it's very hard to reason about this kind of parallelism.

Re: 24 days of Rust – Rayon

#18

Post by [deleted] »

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…

[deleted]

Re: 24 days of Rust – Rayon

#19

Post by lukaslalinsky »

pcwalton wrote: post #16
lukaslalinsky wrote: post #11

Earlier quoted context omitted.

The answer to the questions is that you wouldn't do that in Go. Go doesn't have features that would allow you to do something like this efficiently. You are pretty much limited by the language. You can do high-level abstractions, not something low-level like this and I think that's where the simplicity comes from.

How does not being able to write the high-level par_iter() abstraction make Golang more high-level?

I didn't say Go is more high-level, I said Go doesn't allow you to do low-level things efficiently. Writing your own parallelism library requires good access to the language's execution model internals. Go doesn't give you that, because Go wants you to write application code, not library code. It's often frustrating, because sometimes you want to write a generic low-level library that will add no overhead to the code that uses is, but on the other hand it's very liberating, because you know what you have available and you instead focus on your application code.

Re: 24 days of Rust – Rayon

#20

Post by tatterdemalion »

lukaslalinsky wrote: post #19
pcwalton wrote: post #16

Earlier quoted context omitted.

How does not being able to write the high-level par_iter() abstraction make Golang more high-level?

I didn't say Go is more high-level, I said Go doesn't allow you to do low-level things efficiently. Writing your own parallelism library requires good access to the language's execution model internals. Go doesn't give you that, because Go wants you to write application code, not library code. It's often frustrating, because sometimes you want to write a generic low-level library that will add no overhead to the code…

It would be accurate to say that Go gives you neither low level control nor high level abstraction, whereas Rust gives you both.
Post reply on HN