14 ms·

Maybe because I'm not familiar with Rust, but I always have kind of impressions that Rust code is very hard to read. It is just impossible to figure out what th

Maybe because I'm not familiar with Rust, but I always have kind of impressions that Rust code is very hard to read. It is just impossible to figure out what the code is doing for beginners. [C++ code]: https://github.com/parallel-rust-cpp/shortcut-comparison/blob/8cdab059d22eb8f30e1408c2fbf0ae666fa231d9/src/cpp/v7_cache_reuse/step.cpp https://github.com/parallel-rust-cpp/shortcut-comparison/blo... [Rust code]: https://github.com/parallel-rust-cpp/shortcut-comparison/blob/8cdab059d22eb8f30e1408c2fbf0ae666fa231d9/src/rust/v7_cache_reuse/src/lib.rs https://github.com/parallel-rust-cpp/shortcut-comparison/blo...

xlc0212 7y ago
How is C++ code better? Rust code is harder to write, but I don’t find it harder to read.
_pferreir_ 7y ago
It's not the most readable Rust code I've ever seen and I guess that's not the main concern here. That said, I guess people find C++ easier because they're already used to the syntax.
- blub 7y ago
  Even an amateur C++ programmer or C programmer would understand what that C++ code does. The only slightly opaque thing is the std::tie call. I'd feel comfortable having one of my C-focused colleagues modifying that C++ code. The Rust code is... typical Rust. The algorithm almost gets lost in the specific peculiarities.
  - the_why_of_y 7y ago
    The first thing an amateur C++ programmer would notice is that that code isn't standard C++ code, what with its weird "#pragma omp" thing that isn't in the index of the Stroustrup book.
    - gpderetta 7y ago
      the nice thing about those pragmas is that the code has can be understood even if you ignore them. I do not know if this is true for all omp pragmas (IIRC some the newer ones might have some non ignorable semantics) but it is true for this omp for.
      - the_why_of_y 7y ago
        Yes, of course - a language extension can often give you better ergonomics than a library interface, both in implementing the code and in diagnostics reporting. The downside is that it's more effort to implement a language extension, it's more difficult to evolve it, and it restricts user's choice of implementation to those that have implemented the extension. For example, Microsoft Visual C++ supports only OpenMP 2.0, from 2002. An interesting question in this context would be, is there anything preventing adding an OpenMP extension to Rust?
        gpderetta 7y ago
        Of course there is a cost in making something part of the language, and the C++ way has always been to put features in the library whenever possible. Regarding choice of implementation, there are more C++ compilers that support OpenMP than rust compilers.
        pcwalton 7y ago
        Rayon is basically the "OpenMP of Rust" already. OpenMP is designed around C-style for loops, which Rust discourages.
        gpderetta 7y ago
        FWIW OpenMP supports any C++ random access iterator and c++11 range-for loops. I guess you count any external iterator as C-style loop.
        MauranKilom 7y ago
vhakulinen 7y ago
I have the opposite: I know Rust, but I hardly know C++ beyond C (granted that I probably could figure out the not-so-easy c++ easier than I would figure out the rust version if I didn't know either). Don't get me wrong, I know what you mean. But the same can happen with many other languages too.
lugg 7y ago
Rust is a very terse language. Inexperienced devs tend to write overly compressed code. That example isn't too bad once you're used to the syntax and idioms but the lack of white space to space out logical blocks is what's making it hard to read. Well, that and only what I can say equates to writing C++ in rust, much the same way you can write php in JavaScript if you squint hard enough. Probably doesn't help it's trying to be a comparison which doesn't really work. A lot of that could be refactored out into idiomatic rust and it wouldn't look so bizarre.
rat9988 7y ago
I don't think it is very hard to parse. I think it is very ugly though. Which kind of makes it unreadable. I mean reading fn is not natural for me. Reading function is way more natural. I feel like the language designers didn't pay attention at all to how natural it will look to developers
- pcwalton 7y ago
  > I feel like the language designers didn't pay attention at all to how natural it will look to developers This is not true. We agonized over syntax decisions. "fn" was actually preferred by most of the Rust community.
  - blub 7y ago
    Then the only reasonable conclusion is that the Rust community has different tastes compared to the mainstream programming community. To put it euphemistically. The Swift team probably also agonized over syntax decisions and they came up with something very different which has won over many people and attracted little criticism.
    - pcwalton 7y ago
      The only concrete thing I've seen brought up so far is that some people don't like the keyword "fn". Swift chose "func". Is there really a huge difference? (I prefer "fn", by the way.) Swift also doesn't have pervasive use of lifetimes like Rust does. Lifetimes, by their nature, always add some level of "noise".
      - blub 7y ago
        When people do make an effort and outline pain points, those are waved away by Rust programmers or deflected by claiming that they like said syntax choice. At the end of the day though, these tiny thing like fn, or the lifetime annotations and the many others add up to an unpleasant experience and less readable code.
exDM69 7y ago
The reason the C++ code looks simple is that it uses OpenMP #pragma parallel for, which is a very easy way of doing very simple loop parallelization. By contrast the Rust example uses parallel iterators from the Rayon crate. If the C++ example had something similar using a C++ library, it would probably be worse. It's not Rust vs. C++, it's OpenMP directives vs. explicitly writing multithreaded code.
- blub 7y ago
  The calls starting with par_ are by far not the biggest readability problem. The Rust code has a lot of noise, whereas the C++ reads like almost like a straight C implementation that anyone could understand.
  - exDM69 7y ago
    Would you like to point out specific instances of this "noise"? The C++ code looks like straightforward "C code" because it's using the OpenMP parallel for. If it dealt with threads explicitly it would not look as pretty. I do agree that the Rust code has some verbosity, for example there are a lot of type annotations and using named constants instead of magic values. For example (C++): int na = (n + 8 - 1) / 8; Versus (you could write this like the above too): let vecs_per_col = (n + simd::f32x8_LENGTH - 1) / simd::f32x8_LENGTH; An example of the type annotations (are they really necessary?): let pack_simd_row = |(i, (vd_stripe, vt_stripe)): (usize, (&mut [f32x8], &mut [f32x8]))| { Comparing the actual internals of the algorithm is quite straightforward, e.g. look at the middle loop (lines 70-82 in Rust vs. 58-97 in C++). Do note that the C++ code is loop unrolled by hand which makes it look simpler. In the Rust code, there's a pretty cool feature where multithreading can be toggled on/off with a compile time flag, see parts with: #[cfg(not(feature = "no-multi-thread"))] If the C++ example wouldn't use OpenMP, this would be pretty impossible to achieve without being noisy too. Also note that even with OpenMP, it would be quite easy to create a memory unsafety issue in the C++ code by for example accessing an array out of bounds inside the loop body. Apart from these, I have no problems reading and understanding the C++ or Rust code (and I'm a noob with Rust).
    - 7y ago
timvisee 7y ago
I think Rust is actually very readable in general. In this snippet the author went through some insane optimization, and opted to use quite a few attributes, those definitely make it look noisy in this case. FFI bindings are verbose and not so clean either.
cranej 7y ago
For me the Rust code is easy to read. Personally I don't think it's reasonable to ask programming languages 'easy to read for people not familiar with them' / 'read like English' / or something similar.
- StreamBright 7y ago
  Why is that? The number one reason I do not like Rust is the use of ', & and so on to represent something that would be trivial to implement with plain English. Example: struct HReq<'a> { } struct HReq<a: LifeTime> { } Isn't that better?
  - steveklabnik 7y ago
    That doesn’t show the difference when you have more than one, and you also didn’t show how much more verbose the usage gets inside the struct. It’s not a language level constraint to name lifetimes with a single letter. But folks tend to not use longer names for good reason.
    - StreamBright 7y ago
      I just have a hard time deciphering what the intention was with these single character things. Are you suggesting to use 'a_lifetime? What is that good reason? I usually use longer names to help the next person reading my code.
      - steveklabnik 7y ago
        Rust was originally implemented in OCaml, and takes a lot of inspiration from it. The ‘a syntax is used by OCaml for generic type parameters. Rust is in a weird spot because we have two different kinds of generic parameters: types and lifetimes. They need to be distinguished from one another somehow. Nobody loves the lifetime syntax, but nobody has ever proposed something that would end up significantly better. I’m not proposing you should use ‘a_lifetime, I’m saying you could. In the end, it ends up obscuring more than helping.
edflsafoiewq 7y ago
The Rust is practically line noise. This is just awful let pack_simd_row = |(i, (vd_stripe, vt_stripe)): (usize, (&mut [f32x8], &mut [f32x8]))| { for (jv, (vx, vy)) in vd_stripe.iter_mut().zip(vt_stripe.iter_mut()).enumerate() { let mut vx_tmp = [std::f32::INFINITY; simd::f32x8_LENGTH]; let mut vy_tmp = [std::f32::INFINITY; simd::f32x8_LENGTH]; for (b, (x, y)) in vx_tmp.iter_mut().zip(vy_tmp.iter_mut()).enumerate() { And I tend to write stuff like this in Rust too. The loops especially. It's just so easy to throw together all those iterator combinators and get some ugly blob that's going to make people's eyes glaze over.
- snaky 7y ago
  Maybe it's time to propose alternative syntax for Rust?
- cogman10 7y ago
  I honestly don't see what's so bad about this. About the only thing that might be more useful is better variable names and maybe a function or two to clear up exactly what's going on. But even still, this is math heavy code. I don't think I've ever seen math heavy code (particularly dealing with matrix manipulation) that didn't end up looking like this.
- brutt 7y ago
  Code is easy to follow. I see no problem there. `pack_simd_row` is lambda: `|arguments: types| { body }` Arguments are: * `i` of type `usize` (unisgned size_t), * tuple (anonymous struct) with two fields: vd_stripe and vt_stripe, which are modified inside of lambda. They are references to fixed size array of 8 floats. Inside function we have loop over result of iterator, which produces tuple with two fields: `jv` and tuple with two fields: `vx` and `vy`. `vx` and `vy` are elements from `vd_stripe` and `vt_stripe`. `jv` is their index. Inside loop we create two temporary mutable variables: `vx_tmp` and `vy_tmp`, which are fixed size array of 8 floats, which are initialized with infinity. Then we have next loop, which goes to modify these temporary arrays in place. And so on.
  - jml7c5 7y ago
thanatropism 7y ago
I’m still learning Rust but from the “looks department” I can say so far that it “looks like” a lot more like Python etc. than the other systems languages. It’s almost like Rust starts from a functional programmer’s perspective and adds the necessary complexity to have a “low level” language, whereas C is a simplified assembler and C++ tries to add “high level” amenities.

xlc0212 7y ago

How is C++ code better? Rust code is harder to write, but I don’t find it harder to read.

_pferreir_ 7y ago

It's not the most readable Rust code I've ever seen and I guess that's not the main concern here. That said, I guess people find C++ easier because they're already used to the syntax.

blub 7y ago
Even an amateur C++ programmer or C programmer would understand what that C++ code does. The only slightly opaque thing is the std::tie call. I'd feel comfortable having one of my C-focused colleagues modifying that C++ code. The Rust code is... typical Rust. The algorithm almost gets lost in the specific peculiarities.
- the_why_of_y 7y ago
  The first thing an amateur C++ programmer would notice is that that code isn't standard C++ code, what with its weird "#pragma omp" thing that isn't in the index of the Stroustrup book.
  - gpderetta 7y ago
    the nice thing about those pragmas is that the code has can be understood even if you ignore them. I do not know if this is true for all omp pragmas (IIRC some the newer ones might have some non ignorable semantics) but it is true for this omp for.
    - the_why_of_y 7y ago
      Yes, of course - a language extension can often give you better ergonomics than a library interface, both in implementing the code and in diagnostics reporting. The downside is that it's more effort to implement a language extension, it's more difficult to evolve it, and it restricts user's choice of implementation to those that have implemented the extension. For example, Microsoft Visual C++ supports only OpenMP 2.0, from 2002. An interesting question in this context would be, is there anything preventing adding an OpenMP extension to Rust?
      - gpderetta 7y ago
        Of course there is a cost in making something part of the language, and the C++ way has always been to put features in the library whenever possible. Regarding choice of implementation, there are more C++ compilers that support OpenMP than rust compilers.
      - pcwalton 7y ago
        Rayon is basically the "OpenMP of Rust" already. OpenMP is designed around C-style for loops, which Rust discourages.
        gpderetta 7y ago
        FWIW OpenMP supports any C++ random access iterator and c++11 range-for loops. I guess you count any external iterator as C-style loop.
        MauranKilom 7y ago

vhakulinen 7y ago

I have the opposite: I know Rust, but I hardly know C++ beyond C (granted that I probably could figure out the not-so-easy c++ easier than I would figure out the rust version if I didn't know either). Don't get me wrong, I know what you mean. But the same can happen with many other languages too.

lugg 7y ago

Rust is a very terse language. Inexperienced devs tend to write overly compressed code. That example isn't too bad once you're used to the syntax and idioms but the lack of white space to space out logical blocks is what's making it hard to read. Well, that and only what I can say equates to writing C++ in rust, much the same way you can write php in JavaScript if you squint hard enough. Probably doesn't help it's trying to be a comparison which doesn't really work. A lot of that could be refactored out into idiomatic rust and it wouldn't look so bizarre.

rat9988 7y ago

I don't think it is very hard to parse. I think it is very ugly though. Which kind of makes it unreadable. I mean reading fn is not natural for me. Reading function is way more natural. I feel like the language designers didn't pay attention at all to how natural it will look to developers

pcwalton 7y ago
> I feel like the language designers didn't pay attention at all to how natural it will look to developers This is not true. We agonized over syntax decisions. "fn" was actually preferred by most of the Rust community.
- blub 7y ago
  Then the only reasonable conclusion is that the Rust community has different tastes compared to the mainstream programming community. To put it euphemistically. The Swift team probably also agonized over syntax decisions and they came up with something very different which has won over many people and attracted little criticism.
  - pcwalton 7y ago
    The only concrete thing I've seen brought up so far is that some people don't like the keyword "fn". Swift chose "func". Is there really a huge difference? (I prefer "fn", by the way.) Swift also doesn't have pervasive use of lifetimes like Rust does. Lifetimes, by their nature, always add some level of "noise".
    - blub 7y ago
      When people do make an effort and outline pain points, those are waved away by Rust programmers or deflected by claiming that they like said syntax choice. At the end of the day though, these tiny thing like fn, or the lifetime annotations and the many others add up to an unpleasant experience and less readable code.

exDM69 7y ago

The reason the C++ code looks simple is that it uses OpenMP #pragma parallel for, which is a very easy way of doing very simple loop parallelization. By contrast the Rust example uses parallel iterators from the Rayon crate. If the C++ example had something similar using a C++ library, it would probably be worse. It's not Rust vs. C++, it's OpenMP directives vs. explicitly writing multithreaded code.

blub 7y ago
The calls starting with par_ are by far not the biggest readability problem. The Rust code has a lot of noise, whereas the C++ reads like almost like a straight C implementation that anyone could understand.
- exDM69 7y ago
  Would you like to point out specific instances of this "noise"? The C++ code looks like straightforward "C code" because it's using the OpenMP parallel for. If it dealt with threads explicitly it would not look as pretty. I do agree that the Rust code has some verbosity, for example there are a lot of type annotations and using named constants instead of magic values. For example (C++): int na = (n + 8 - 1) / 8; Versus (you could write this like the above too): let vecs_per_col = (n + simd::f32x8_LENGTH - 1) / simd::f32x8_LENGTH; An example of the type annotations (are they really necessary?): let pack_simd_row = |(i, (vd_stripe, vt_stripe)): (usize, (&mut [f32x8], &mut [f32x8]))| { Comparing the actual internals of the algorithm is quite straightforward, e.g. look at the middle loop (lines 70-82 in Rust vs. 58-97 in C++). Do note that the C++ code is loop unrolled by hand which makes it look simpler. In the Rust code, there's a pretty cool feature where multithreading can be toggled on/off with a compile time flag, see parts with: #[cfg(not(feature = "no-multi-thread"))] If the C++ example wouldn't use OpenMP, this would be pretty impossible to achieve without being noisy too. Also note that even with OpenMP, it would be quite easy to create a memory unsafety issue in the C++ code by for example accessing an array out of bounds inside the loop body. Apart from these, I have no problems reading and understanding the C++ or Rust code (and I'm a noob with Rust).
  - 7y ago

timvisee 7y ago

I think Rust is actually very readable in general. In this snippet the author went through some insane optimization, and opted to use quite a few attributes, those definitely make it look noisy in this case. FFI bindings are verbose and not so clean either.

cranej 7y ago

For me the Rust code is easy to read. Personally I don't think it's reasonable to ask programming languages 'easy to read for people not familiar with them' / 'read like English' / or something similar.

StreamBright 7y ago
Why is that? The number one reason I do not like Rust is the use of ', & and so on to represent something that would be trivial to implement with plain English. Example: struct HReq<'a> { } struct HReq<a: LifeTime> { } Isn't that better?
- steveklabnik 7y ago
  That doesn’t show the difference when you have more than one, and you also didn’t show how much more verbose the usage gets inside the struct. It’s not a language level constraint to name lifetimes with a single letter. But folks tend to not use longer names for good reason.
  - StreamBright 7y ago
    I just have a hard time deciphering what the intention was with these single character things. Are you suggesting to use 'a_lifetime? What is that good reason? I usually use longer names to help the next person reading my code.
    - steveklabnik 7y ago
      Rust was originally implemented in OCaml, and takes a lot of inspiration from it. The ‘a syntax is used by OCaml for generic type parameters. Rust is in a weird spot because we have two different kinds of generic parameters: types and lifetimes. They need to be distinguished from one another somehow. Nobody loves the lifetime syntax, but nobody has ever proposed something that would end up significantly better. I’m not proposing you should use ‘a_lifetime, I’m saying you could. In the end, it ends up obscuring more than helping.

edflsafoiewq 7y ago

The Rust is practically line noise. This is just awful let pack_simd_row = |(i, (vd_stripe, vt_stripe)): (usize, (&mut [f32x8], &mut [f32x8]))| { for (jv, (vx, vy)) in vd_stripe.iter_mut().zip(vt_stripe.iter_mut()).enumerate() { let mut vx_tmp = [std::f32::INFINITY; simd::f32x8_LENGTH]; let mut vy_tmp = [std::f32::INFINITY; simd::f32x8_LENGTH]; for (b, (x, y)) in vx_tmp.iter_mut().zip(vy_tmp.iter_mut()).enumerate() { And I tend to write stuff like this in Rust too. The loops especially. It's just so easy to throw together all those iterator combinators and get some ugly blob that's going to make people's eyes glaze over.

snaky 7y ago
Maybe it's time to propose alternative syntax for Rust?
cogman10 7y ago
I honestly don't see what's so bad about this. About the only thing that might be more useful is better variable names and maybe a function or two to clear up exactly what's going on. But even still, this is math heavy code. I don't think I've ever seen math heavy code (particularly dealing with matrix manipulation) that didn't end up looking like this.
brutt 7y ago
Code is easy to follow. I see no problem there. `pack_simd_row` is lambda: `|arguments: types| { body }` Arguments are: * `i` of type `usize` (unisgned size_t), * tuple (anonymous struct) with two fields: vd_stripe and vt_stripe, which are modified inside of lambda. They are references to fixed size array of 8 floats. Inside function we have loop over result of iterator, which produces tuple with two fields: `jv` and tuple with two fields: `vx` and `vy`. `vx` and `vy` are elements from `vd_stripe` and `vt_stripe`. `jv` is their index. Inside loop we create two temporary mutable variables: `vx_tmp` and `vy_tmp`, which are fixed size array of 8 floats, which are initialized with infinity. Then we have next loop, which goes to modify these temporary arrays in place. And so on.
- jml7c5 7y ago

thanatropism 7y ago

I’m still learning Rust but from the “looks department” I can say so far that it “looks like” a lot more like Python etc. than the other systems languages. It’s almost like Rust starts from a functional programmer’s perspective and adds the necessary complexity to have a “low level” language, whereas C is a simplified assembler and C++ tries to add “high level” amenities.