Rust Performance Pitfalls

I believe this needs a stronger warning. Functions that operate on strings are allowed to assume that their input is valid UTF-8 and may perform out-of-bounds memory accesses if the input is not valid UTF-8. Therefore, creating a string containing invalid UTF-8 can lead to a memory safety vulnerability. The suggestion to use this function seems out-of-place in this article, which otherwise avoids suggesting unsafe code (e.g. indexing arrays without bounds checking).

Writing a iterator to provide the individual bits supplied by an iterator of bytes means you can count them with

    fn count_bits<I : Iterator<Item=bool>>(it : I) -> i32{
        let mut a=0;
        for i in it {
            if i {a+=1};
        }
        return a;
    } 

    let p:[u8;6] = [1,2,54,2,3,6];
    let result = count_bits(bits(p.iter().cloned()));

The core of the code is

    .LBB0_4:
        mov     esi, edx        ;edx has the current mask of the bit we are looking at
        and     esi, ecx        ;ecx is the byte we are examining
        cmp     esi, 1          ;check the bit to see if it is set (note using carry not zero flag)
        sbb     eax, -1         ;fun way to conditionally add 1
    .LBB0_1:
        shr     edx             ;shift mask to the next bit
        jne     .LBB0_4         ;if mask still has a bit in it, go do the next bit otherwise continue to get the next byte 
        cmp     rbx, r12        ;r12 has the memory location of where we should stop.   Are we there yet?
        je      .LBB0_5         ; if we are there, jump out. we're all done
        movzx   ecx, byte ptr [rbx]  ;get the next byte
        inc     rbx             ; advance the pointer
        mov     edx, 128        ; set a new mask starting at the top bit
        jmp     .LBB0_4         ; go get the next bit
    .LBB0_5:

If this produces simiarly nice code (I haven't checked yet) I'll be very happy

   for (dest,source) in self.buffer.iter_mut().zip(data) { *dest=source }

    let nopes : Vec<_> = bleeps.iter().map(boop).collect();
    let frungies : Vec<_> = nopes.iter().filter(|x| x > MIN_THRESHOLD).collect();

> for x in &xs { // do something with x }

I am curious why the compiler can't rewrite the former to the latter?

    use std::mem;

    enum MyEnum {
        A { name: String, x: u8 },
        B { name: String }
    }

    fn a_to_b(e: &mut MyEnum) {

        // we mutably borrow `e` here. This precludes us from changing it directly
        // as in `*e = ...`, because the borrow checker won't allow it. Therefore
        // the assignment to `e` must be outside the `if let` clause. 
        *e = if let MyEnum::A { ref mut name, x: 0 } = *e {

            // this takes out our `name` and put in an empty String instead
            // (note that empty strings don't allocate).
            // Then, construct the new enum variant (which will 
            // be assigned to `*e`, because it is the result of the `if let` expression).
            MyEnum::B { name: mem::replace(name, String::new()) }

        // In all other cases, we return immediately, thus skipping the assignment
        } else { return }
    }

This is a good example of the main conceptual aspect of Rust where I feel it could use improvement.[3] A lot of its features marry very high-level concepts (like algebraic data types) to exposed, low-level implementations (like tagged unions). Now, there's nothing wrong with the obvious choice to implement ADTs as tagged unions, but the nature of Rust as a language that exposes low-level control over allocation and addressing, in combination with the strictures of the borrow checker, means enums and other high-level features live in a sort of uncanny valley, falling short of either the high-level expressiveness of ADTs or the low-level flexibility of tagged unions (without expert-level knowledge or using `unsafe`).

Similarly, the functional abstractions almost feel like a step backwards from the venerable C++ <algorithm>, abstraction and composition-wise. Very nitty-gritty, low-level implementation details leak out like a sieve — you can't have your maps or folds without a generous sprinking of `as_slice()`, `unwrap()`, `iter()` / `iter_mut()` / `into_iter()` and `collect()` everywhere, although at least for this case you would be able to figure out the idioms by reading the official docs. But nevertheless it seems like reasonable defaults could be inferred from context (with the possible exception of `collect()` since it allocates), while still allowing explicitness as an option when you want low-level control over the code the compiler generates.

In this case, enums are a language-level construct, not a library, so the borrow-checker really shouldn't be rejecting reasonable patterns. It (legal to alias between the structural and nominal common subsequence of several members of an enum) should be the default behavior and not require an nonobvious, unreadable hack such as the above. At the very least that behavior (invaluable for many low-level tasks) should be easy to opt in to with e.g. an attribute.[4]

[1] https://doc.rust-lang.org/std/mem/fn.replace.html

[2] Or rather since it is a tagged union, in MASMish pseudocode something like

        jnz x_nonzero
        mov MyEnum.B, e.tag
    x_nonzero:
        ret

[3] And I'm not saying I have the solution or even that all-around-better solutions exist.

[4] Something like

    #![safe_alias_common_subsequence(structural)]
    #![safe_alias_common_subsequence(nominal_and_structural)]

What class of algorithms is faster in Rust than it is in C?

Back when Rust used "internal" iterators, this could be the default. Now, you can encapsulate it by passing a function to handle each line.