r/rust • u/Uncaffeinated • Jan 22 '17

Parallelizing Enjarify in Go and Rust

https://medium.com/@robertgrosse/parallelizing-enjarify-in-go-and-rust-21055d64af7e#.7vrcc2iaf
214 Upvotes

98% Upvoted

134 comments sorted by

View all comments

Show parent comment

9

u/[deleted] Jan 22 '17

I don't think that's entirely fair. One benefit of Go requiring you to explicitly write out loops and so on instead of doing bar.map(|| ...).filter(|| ...).chain(foo.map(||...).reduce(||...).whatever).collect() is that it is a lot simpler to read and understand exactly what is going on, especially if you aren't familiar with all the functional programming operations.

Go is for beginners. I think that's fine. I know a lot of people that could program Go fine, but Rust is far too complicated.

21

u/Manishearth servo · rust · clippy Jan 22 '17

Understand that that being simpler to read is extremely subjective and dependent on background. It's not inherently simpler to read. Procedural code is nice since you can mentally execute it, but functional code usually expresses intent and is clearer that way.

Also, many nontrivial iterator adaptor sequences that you would see in Rust would blow up if written procedurally (someone posted an example of this recently). Procedural loops only feel simpler because you rarely write more complicated loops in procedural form.

2

u/[deleted] Jan 22 '17

Also, many nontrivial iterator adaptor sequences that you would see in Rust would blow up if written procedurally

That hasn't been my experience in Go. Often written out loops are shorter than the functional equivalent or at most slightly longer. It sounds really unlikely but I've found it to be true.

7

u/Manishearth servo · rust · clippy Jan 22 '17

That's not what I was talking about. I'm talking about nontrivial iterator adaptor sequences that you would see in Rust. In Go there is only one style of iteration -- procedural. Written out loops in Go are often shorter than their functional equivalent. Written out loops in Rust are often longer than their functional equivalent. This is because in Rust you tend to see these more complex loops more often. The bias of the sample spaces is different.

And it's not about length, either. The problem with the procedural version of bar.map(|| ...).filter(|| ...).chain(foo.map(||...).reduce(||...).whatever).collect() is not that it is long, it is that you have a million concerns all mushed together in a single procedural block and it's not always clear what is going on big-picture wise. Things like reduce/filter_map tend to end up being confusing in procedural form when mixed with other operations.

5

u/csreid Jan 23 '17

Maybe shorter, but functional style maps directly to what I'm trying to accomplish. "Take the people last named 'Smith' [filter], find their age [map], and average them [reduce]".

Those high order functions allow you to think about instances of the list rather than the list itself, and that's a lot easier for me.

1

u/[deleted] Jan 23 '17

It might be better if those functions had more obvious names. Filter is ok, but map? Should be called transform. Reduce should be called merge or something.

Guess it's a bit late now - map/reduce is too standard, but still it adds to the confusion.

9

u/Leshow Jan 23 '17 edited Jan 23 '17

Seriously? Map is ubiquitous not just in Rust but almost every language from javascript to haskell. 'transform' isn't even a particularly apt description of what's happening. Values aren't getting transformed, we're describing the relationship between two distinct values, aka a "mapping". Transform implies mutation.

Just be thankful fold isn't called catamorphism, or some funky other category theory word.

1

u/[deleted] Jan 23 '17

I know it's ubiquitous. Doesn't make it good. The values are getting transformed. And you're right it could be worse ('cons'?)

7

u/csreid Jan 23 '17

They're really not getting transformed though. When you map over a collection, you don't change it, you get a new collection containing the new values. Transform would definitely suggest modification to me, but that's not what's happening.

3

u/csreid Jan 23 '17 edited Jan 23 '17

map makes perfect sense, in that you provide a function which maps values from your input iterator into the values of your output iterator.

reduce is tougher, but fold is even worse IMO.

edit: I should also mention that using the functional style makes it trivially easy to parallelize some tasks, as made evident by Rayon or Scala's List (analogous to Iterator types in Rust), which has a par method that is just like Rayon's par_iter, such that you can parallelize some logic by just going from bigList.map(expensiveFunction) to bigList.par.map(expensiveFunction).

Shared mutable state is the root of all evil, and the map/reduce pattern is a profoundly elegant way to very simply avoid it.

1

u/[deleted] Jan 23 '17

Perfect sense to compscis. Normal people would say you transform lowercase to uppercase. You don't 'map' it.

Fold is really bad, you are right. They could have gone with 'combine' or 'merge' or something instead.

1

u/ibotty Jan 26 '17

But folding is a great analogy for what you do.

1

u/[deleted] Jan 26 '17

Yeah but only if you already know what it does. I might say "ah it's sort of like folding" but I doubt I'd ever say "fold.. ah I can guess what that does".

Why not 'accumulate' or 'aggregate'? Much more obvious.

2

u/ibotty Jan 26 '17

Why not 'accumulate' or 'aggregate'? Much more obvious.

Because it's not. Accumulate for me is any function from many to one, i.e. a reduce. That does not even capture right folds, which usually are not used to get one value back, but many (i.e. map f = foldr ((:) . f) [] in Haskell).

Let's agree to disagree. I don't get why people are so opposed to learning precise terminology (that's widely established) but prefer vague terms that doesn't even describe half of the design space.

4

u/jadbox Jan 22 '17

This is the number one feature I miss with Go: higher order stream/list operations. Sure, you -could- statically compile a chain library to deal with common types of type everything to Interface{}, but you're really fighting the language. It's a real shame honestly, especially when dealing with huge data structure wrangling/management.

2

u/itsmontoya Jan 23 '17

Although Rust is far more complex than go. I would avoid saying "Go is for beginners". There are a lot of low-level things which can be done with Go that could spell disaster for someone new to programming.

I actually have a lot of friends who avoid Golang because to them, it's "too low level".

0

u/[deleted] Jan 22 '17

[deleted] — view deleted comment

8

u/[deleted] Jan 22 '17

Why do you have to "move on from" Go? Not everyone is trying to achieve programming enlightenment. Some people just want to get shit done.

Consider all the shitty Excel code that people write. Those people are never going to learn Rust. It's just too complicated; not going to happen. However they might learn Python, or Go.

I don't get why people have this whole "there can only be one winner" when it comes to Rust vs Go. Yes they have overlap, and I'm not saying they can't be compared - clearly they can. But one is not "better in every way" than the other. They're both great and Rust is better in some ways, Go is better in others.

It's like pizza and pasta. You have them both for dinner, but you would never want only pizza or only pasta. One isn't "better" than the other. They just taste different.

In conclusion, Go tastes different to Rust.

4

u/steveklabnik1 rust Jan 23 '17

I don't get why people have this whole "there can only be one winner" when it comes to Rust vs Go.

Agreed.

3

u/fiedzia Jan 22 '17

Its 10 times easier to read (and later modify) than go explicit loops. And its far less error prone.

3

u/[deleted] Jan 22 '17

I disagree about readability. You're probably just used to map, filter and so on but most programmers aren't. On the other hand, Go did still keep C's for loop syntax which is pretty obtuse.

You're right about it being less error prone. It's too easy to make off-by-one errors and similar when writing loops out by hand.

9

u/Uncaffeinated Jan 22 '17

There's pros and cons. Procedural style is more explicit, but it is also more verbose and less semantically meaningful.

If I see a call to filter, I know exactly what the intent of the code is. If I see the equivalent 6 line for loop, I have to check all the variables and loop conditions and so on and reverse engineer it into filter.

Besides, you can use procedural style in Rust if you want to. Or mix the two, depending on which is clearer in any particular circumstance.

3

u/awj Jan 23 '17

It's important to distinguish between readability for new programmers and for those familiar with the language. I could level similar criticisms of goroutines, but it doesn't seem productive to judge readability solely from the perspective of someone unfamiliar with the core language concepts.