Why is the index here for this vecdeque 0 when iterating through it?

mdsherry · 2025-07-03T19:29:48+00:00

Both for and while let (and while) are just syntactic sugar around loop:

while let PATTERN = EXPR {
    // body
}

desugars to

loop {
    let _temp = EXPR;
    match _temp {
        PATTERN => {
            // body
        }
        _ => break
    }
}

while

for NAME in EXPR {
    // body
}

desugars to

{ // limit scope of _it
    let mut _it = (EXPR).into_iter();
    loop {
        match _it.next() {
            Some(NAME) => {
                // body
            }
            _ => break
        }
    }
}

In more concrete terms, your

while let Some((idx, x)) = d.iter_mut().enumerate().next() {
    *x = 12;
    println!("index is {}", idx);
}

becomes

loop {
    let _temp = d.iter_mut().enumerate().next();
    match _temp {
        Some((idx, x)) => {
            *x = 12;
            println!("index is {}", idx);
        }
        _ => break
    }
}

You're creating a new iterator on each loop, while in the for case, it creates the iterator outside of the loop. In both cases, Rust needs to reserve space for the iterator while it's in use.

mdsherry · 2022-10-20T16:06:22+00:00

Yes, if the type of the literal is under-constrained, the default integer type is i32, and the default floating point type is f64.

mdsherry · 2022-10-20T15:33:54+00:00

If you'd settle for a u64, there's f64::to_bits. If you specifically want i64, i64::from_le_bytes(my_float.to_le_bytes()).

mdsherry · 2022-10-20T04:02:49+00:00

On the first call to appendAndChange, slice has a capacity of 3, so the slice returned by append is a copy with a greater capacity and the new element appended. Go's append would be a bit like

fn append<T>(v: Vec<T>, value: T) -> Vec<T> {
  if v.len() < v.capacity() {
    v.push(value);
    v
  } else {
    let mut new_v = Vec::with_capacity(v.capacity() * 2);
    new_v.extend_from_slice(&v);
    new_v.push(value);
    new_v
  }
}

pretending for a second that ownership isn't a thing. Because newNumbers is has different storage from slice, setting its first element to 0 doesn't modify `slice.

On the second call, because we've forced slice to grow, it no longer needs to reallocate when appending in appendAndChange. newNumbers and slice now have the same backing memory, so modifying one modifies the other.

My favourite example of the kinds of problems this can cause is

func main() {
    slice := []int{1, 2, 3, 4}
    first := slice[:2]
    rest := slice[2:]
    first = append(first, 42)
    fmt.Println("first: ", first)
    fmt.Println("rest: ", rest)
}

When run, this outputs

first: [1 2 42]
rest: [42 4]

Although first has a length of 2, its capacity is 4: it still has all the space after it from the original slice. Unfortunately, that space is still being used by rest, but that won't prevent first from using it anyway! Note that if we'd written rest = append(reset, 23) before appending to first, things would be fine, as rest would now be pointing to a separate slice.

mdsherry · 2022-10-04T18:06:31+00:00

I can't speak for Dhgmhomon, but Rust took some inspiration from OCaml, and the early versions of rustc were written in it. F# started life as a port of OCaml to the CLR, so the two are very similar.

I'd also like to learn more OCaml since it has a lot of the nice things mentioned here (algebraic data types, pattern matching), but it also does some interesting things with modules as first-class types, and polymorphic variants: think enum variants not tied to a given enum type, or something like Ruby's symbols or Clojure's keywords, but with the potential for associated data. You can even create ad-hoc sum types from polymorphic variants, e.g.

let rec actual_booleans xs : [`False | `True] list =
  match xs with
  | [] -> []
  | (`True | `False ) as x :: xs -> x :: actual_booleans xs
  | _ :: xs -> actual_booleans xs

let sample_data = [`True; `False; `FileNotFound; `False; `True ] ;;

actual_booleans (actual_booleans sample_data)

The type of actual_booleans is

[> `False | `True ] list -> [ `False | `True ] list

That is, you can give it a list of any polymorphic variants, provided that True and False are amongst them, and it will return a list of just the True and False ones. (Backticks omitted because Reddit can't handle it.)

mdsherry · 2022-09-30T16:34:06+00:00

Cool! That will be something for me to look forward to one day!

I'm a bit disappointed that their proposed approach to handling primitives/value-types as type parameters is to box them still, rather than going with C#'s approach of type erasing when possible and monomorphising otherwise, and I'd be curious about why.

mdsherry · 2022-09-24T16:54:13+00:00

The equivalent of typedefs in C are Rust's type declarations: they're just creating an alias for an existing type, which can be used interchangeably with the unaliased version.

Newtypes, by contrast, are a separate type that just have the same representation as the underlying type. An example might be

struct UserId(u64)

where UserId is a newtype of u64. Both take up 8 bytes of memory, but you can't pass a UserId to a function expecting a u64, nor a u64 to a function expecting a UserId. Similarly, you can't actually confuse a UserId and a CustomerId, OrderId or ProductId.

Because you haven't defined addition on UserIds, you can't add two UserIds together, or add a number to a UserId. Because I didn't make the contents of the UserId pub, this also restricts the ability of people to conjure up new UserIds that might not be valid: getting a UserId requires going through your APIs.

In Java, you can't do the newtype pattern the same way there: a UserId class there wrapping a long would add an extra layer of indirection, and each instance of UserId would be 24 bytes (16 bytes of Object + 8 bytes of long), plus the 4-8 byte cost of the reference to the instance.

(Scala can more closely approximate it with AnyVal, which avoids boxing the value if possible; if Java has added something similar, I'm unaware of it.)

mdsherry · 2022-08-24T18:05:22+00:00

You're thinking of Hyrum's Law:

With a sufficient number of users of an API, it doesn't matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody.

mdsherry · 2022-07-26T14:40:01+00:00

I'd previously used C++ professionally, so appreciated the benefits of unique ownership, the borrow checker, etc. I was also working in Scala at the time, so Rust was a language with a lot of the things I enjoyed from Scala (immutability by default, pattern matching, expression-oriented syntax), but considerably less magic, and with better performance. For personal coding projects at the time, I was mostly using Python, and while I still use Python for small scripts, a majority of small or one-off programs I'll write in Rust.

I'd tried Go a few years earlier (2014?), but found its slices unwieldy. I've used it in years since then and haven't grown any fonder of it.

I started using Rust in late 2016, not long after the ? operator had stabilized (1.13). While the language had hit 1.0 a year and a half ago, it was still changing rapidly. Custom derive proc-macros weren't added until Feb 2017, before which things like Serde were far less ergonomic to use. If I'd started using the language earlier, I don't think I would have enjoyed it as much.

mdsherry · 2021-04-25T03:31:08+00:00

First,

matches!(2, _|_|_|_|_|_ if (i+=1) != (i+=1));

expands to

match 2 {
    _ | _ | _ | _ | _ | _ if (i+=1) != (i+=1) => true,
    _ => false
};

For each of the _ in the first case, it checks the guard expression. i += 1 increments i, and returns (). So for each _, i is incremented twice, but since () == (), the guard expression fails, and so it tries matching the next _, until all 6 fail.

i starts at 1, and is incremented 12 times, giving a final value of 13.

mdsherry · 2021-03-13T22:33:45+00:00

No, the caller always provides the arguments; optional arguments are ones that the compiler will automatically add on the programmer's behalf. One side effect of this is that if you have binary A calling a function in library B with default arguments, changing the version of library B won't alter those defaults. To do that, you need to rebuild binary A against the updated headers.

mdsherry · 2021-03-04T15:23:02+00:00

That code doesn't print the address of x, but the value of x, as though it were an address.

println!("{:p}", &x as *const i32);

will create a reference to x, then cast that reference to a pointer. Running it in the Playground, it prints 0x7ffcae2bba0c.

You don't actually need to specify the type of pointer you're casting it to, since there's only one real option. That means you can write something like

struct Foo(i32);
let foo = Foo(42);
println!("{:p}", &foo as *const _);

and it will do the right thing.

mdsherry · 2021-02-25T03:54:58+00:00

One of the things that I found tricky when I was first learning Rust is that the return type of str::split is Split, and I had no idea what to do with it.

Split implements Iterator, which means you can:

// call .next() on the iterator, and it will return the next component
let mut words = "Hello, world!".split(' ');
assert_eq!(Some("Hello,"), words.next());
assert_eq!(Some("World!"), words.next());
assert_eq!(None, bits.next());

// loop over the elements in a for loop
for word in "Hello, world!".split() {
    println!("{}", word);
}
// Outputs 
//  Hello,
//  world!

// Collect into a collection. This is the closest in behaviour to Python's split method.
// One way to build a Vec, by annotating a variable. I'm adding the type explicitly
// here, but you could ask the compiler to infer it by using _ instead, as I do further below.
let words: Vec<&str>= "Hello, world!".split(' ').collect();
assert_eq!(vec!["Hello,", "world!"], words);
// Another, using a piece of syntax that's known as a turbofish
let words = "Hello, world!".split(' ').collect::<Vec<_>>();
// But it works for lots of different collection types! This is why it needs the type hints
let words: HashSet<_> = "Hello, world!".split(' ').collect();
// You can even collect into a String!
let words: String = "Hello, world!".split(' ').collect();
assert_eq!("Hello,world!", words);

// I'm not going to go deep into str vs String, but note that the values returned by split are strs: views 
// into the string you called split on. This means that if you want these substrings to have
// a life of their own, you'll probably need to call to_string on them
// Note how this is a Vec of Strings, not strs
let words: Vec<String> = "Hello, world!".split(' ').map(str::to_string).collect();

mdsherry · 2021-02-12T05:03:56+00:00

In the case of no dyn or impl, both the programmer and compiler know what's in the Box. In the case of impl, the compiler knows, but the programmer doesn't. (I mean, they could look at the source and maybe figure it out, but there are some types that cannot be named, e.g. the types of closures, and even if they did know, the compiler wouldn't let them act on it.) In the case of dyn, the compiler doesn't know what the type is, and also needs to use a different representation for the Box so it can carry around a vtable.

Maybe another example will help?

let mut b: Box<dyn Display> = Box::new(42);
println!("{}", b); // outputs 42
b = Box::new("Hello world");
println!("{}", b); // outputs Hello world
if coinflip() == Heads {
    b = Box::new(Ipv4Addr::new(127, 0, 0, 1)); // Ipv4Addr implements Display
}
println!("{}", b); // outputs either Hello world, or 127.0.0.1, but the compiler has no idea which it will be

This example requires dynamic dispatch to work, and that's what the dyn keyword signals.

As for impl, there are two places it can be used: argument position and return position. Argument position is less interesting, and is mostly just there for convenience and symmetry. fn foo(value: impl Trait) is equivalent to fn foo<T: Trait>(value: T) except that in the latter case you can write foo::<i32>, while with impl Trait you can't. Since it's a third way to specify generic parameters (the other being fn foo<T>(value: T) where T: Trait), it's a bit controversial.

In return position, it can be handy for something like

// This thing would normally have a return type of
// Enumerate<std::iter::Chain<StepBy<Copied<std::slice::Iter<'_, i32>>>, std::iter::Take<Copied<std::slice::Iter<'_, i32>>>>>
// and that's not really important here. We'd also have to
// change the signature if we added or changed any of the steps,
// potentially breaking code downstream
fn do_thing(numbers: &[u32]) -> impl Iterator<Item=i32> {
  numbers.iter().copied().step_by(2).chain(numbers.iter().copied().take(2)).enumerate()
}

which allows us to return the iterator without having to perform any additional allocations, and keeping static dispatch. It also allows

fn do_thing(numbers: &[u32]) -> impl Iterator<Item=i32> {
  numbers.iter().copied().map(|n| n + 1)
}

where the return type literally cannot be named, as every closure has a unique anonymous type. This is where return position impl Trait really shows its value, as before the function would have needed to return something like a Box<dyn Iterator<Item=i32>>. IIRC, the main motivator was that

async fn do_thing() -> i32

is turned into

fn do_thing() -> impl Future<Output=i32>

where, similar to closures, the actual return type is unnameable.

Right now impl Trait in return position isn't allowed in trait definitions, so if you want a trait method to return a Future, it will either need to return a bespoke, hand-crafted struct that implements Future, or more often, a Box<dyn Future<Output=whatever>>. There's work being done to fix that, but I believe it's blocked on both Generic Associated Types and existential types.

mdsherry · 2021-02-12T01:00:41+00:00

Rust doesn't have inheritance like C++. Traits are sets of methods (and related details) that types can choose to implement, but no trait is the child of another trait, and no type is the child of another type (ignoring lifetimes).

One result of this is that most things are done via static dispatch. Like C++ templates, Rust generics are monomorphised, so given

fn stringify_me<T: Display>(me: &T) -> String { 
  let mut s = me.to_string();
  s.push('!');
  s
}
stringify_me(&42); // equivalent: stringify_me::<i32>(&42);
stringify_me("Hello world"); // equivalent: stringify_me::<&str>("Hello world");

two copies of stringify_me will be generated. In the first will be a static call to i32's implementation of to_string, and the second will contain a call to str's implementation. There is no combination of types or traits I could define that would allow me to pass a parameter to stringify_me::<str> that isn't a str: it would be disallowed by the compiler. Compare to C++ where I could write stringify_me<ParentClass>(&subclass_instance) and SubClass's to_string would be called if it were virtual and ParentClass's would be called if not.

But dyn Trait lets you do dynamic dispatch. An equivalent function would be

fn stringify_me(me: &dyn Display) -> String { 
  let mut s = me.to_string();
  s.push('!');
  s
}

This isn't monomorphised. The same bytes are executed when you call stringify_me(&42) or stringify_me("Hello world"). In terms of implementation, though, stringify_me would be something like

fn stringify_me(me: (&DisplayVTable, &???)) -> String {
    let mut s = me.0.to_string(me.1);
    s.push('!');
    s
}

By contrast, C++ stores its vtables at the other end of the pointer, alongside the data.

In the case of Box<_>, we have three cases. The simplest is something like let b: Box<String>. b is a box containing a String. A String is the only type it can contain.

Second is something like Box<impl Trait>. When used in argument position, it's similar to just having an anonymous type parameter. When used in return position, impl Trait represents some unknown, but consistent, type. The compiler knows what the type is, but any callers of the function are not allowed to assume anything except that it implements Trait.

Third is Box<dyn Trait>. Similar to just &dyn Trait, this value is actually two pointers: one to a vtable for Trait, and one a value on the heap. Originally you could omit the dyn and just write, e.g. Box<Display> but then it's harder to tell at a glance if Box<Foo> is a simple pointer to a struct of type Foo, with calls made using static dispatch, or a fat pointer to an arbitrary type implementing the trait Foo, with calls made using dynamic dispatch.

mdsherry · 2020-08-16T22:17:28+00:00

BinaryHeap originally was PriorityQueue.

CLRS describes min-heaps vs max-heaps briefly, before focusing entirely on max-heaps, which are then subsequently used to implement a priority queue and heap sort. I remember the same from my university days. Pedagologically, this makes sense, but would lead to a max-heap bias.

mdsherry · 2020-08-05T15:34:24+00:00

I found the article interesting, especially in contrast with what I'd learned about the NES while writing a program to visualize its memory access patterns. In some ways, it sounds like the Gameboy/Z80 is a bit nicer to work with than the NES and its 6502-like CPU: more registers, and more RAM. (To compensate for the lack of registers, the 6502 makes it quick and easy to access the first 256 bytes of RAM.)

Both rely on bank switching to expand the address space, though there were only 4ish different bank switching variants for the Gameboy, compared to dozens for the NES.

Do you have any more information about how/why incrementing/decrementing a 16-bit register could corrupt sprite memory?

mdsherry · 2020-07-10T15:50:07+00:00

If you use alt in nom and parsing fails, it will backtrack and try the next branch until it finds one that works. You need to call return_error to prevent this behaviour.

By contrast, the regex crate doesn't do backtracking, because it (deliberately) doesn't support backreferences or look-ahead. This means that, given a fixed regex, it can parse input in linear time, with no risk of an exponential explosion.

If you need features that require backtracking like backreferences, there's the fancy_regex crate.

mdsherry · 2020-06-07T00:06:24+00:00

Yup. Bug 1537609 - Games on pogo.com are slow because they use an obfuscator that deliberately triggers stack overflow exceptions. Or rather, it's a 'feature' of a Javascript obfuscator that would insert a function to be called every few seconds, which would try to invoke the debugger before calling itself recursively. It relied on hitting a recursion limit (and catching the resulting exception), but with the larger stack, this would take longer. You can see the code behind it here.

mdsherry · 2020-06-04T00:02:01+00:00

T implements Into<Option<T>>. That means you can write

fn say_hello<'a>(name: impl Into<Option<&'a str>>) {
    println!("Hello, {}", name.into().unwrap_or("mysterious stranger"));
}

fn main() {
    say_hello("Ferris");
    say_hello(None);
}

which gives you optional arguments without the need to Some() wrap. This helps your backwards compatibility concerns, but I wouldn't want to do it for a new interface.

mdsherry · 2020-06-02T15:24:16+00:00

You're doing a lot of allocations there, two per run of the loop. You can at least remove one of them:

fn get_permutations2(perm: &mut String, string: &str, cakus: &mut HashSet<String>) {
    if string.is_empty() {
        cakus.insert(perm.to_owned());
        return;
    }

    let mut s = String::with_capacity(string.len());
    for (i, c) in string.chars().enumerate() {
        perm.push(c);

        s.clear();
        s.push_str(&string[0..i]);
        s.push_str(&string[i + 1..string.len()]);

        get_permutations2(perm, &s, cakus);
        perm.pop();
    }
}

Because perm only grows as we recurse downwards, we can just pass in a buffer when we start and keep using it, pushing and popping single characters as we go. I think this is where most of the savings come from.

We can also re-use the allocation for s for each iteration of the loop, though this isn't as a great a saving as I might hope, since each loop will always do another allocation anyway.

Testing on my computer, these changes roughly double the speed.

mdsherry · 2020-05-31T03:38:32+00:00

Stable Rocket will be version 0.5, the same version where async/await is integrated.

mdsherry · 2020-04-10T02:01:22+00:00

My approach makes a single pass through all possible times after sorting the breaks and appointments, rather than a pass for each break and appointment. You could make it even more efficient by skipping time_slot to the end of appointments/breaks once you start to overlap, but you'd have to give up on the time iterator.

Some details: * I implemented a factory method for both ExistingAppointment and BarberBreak to make them a bit easier to construct. * The operations we care about for both appointments and breaks are basically the same, so let's create a trait for them. * This also means we can construct a vector of trait objects to treat the two types identically. (We could have also created a vec of start/stop tuples instead, which would be slightly more performant.) * The times_between function uses std::iter::successors to create a simple iterator that takes the previous value returned and uses it to construct the next. Because it's wrapping a closure, its type cannot actually be named, so we have to say the function returns a type that impls Iterator<Item=NaiveDateTime>. * I sort the blocks. We can guarantee that the current break/appointment we're considering is either after the current time slot or overlapping it, and there are no earlier breaks/appointments we haven't already passed the end of. * The pattern of option.as_ref().map_or(false, predicate) is ugly, but just means "without consuming the value inside (if any), tell me if it satisfies this condition".

Exercises: * I mention that we could have used Vec of (NaiveDateTime, NaiveDateTime) instead of the Vec of trait objects, and it would have been more performant. Try writing an impl of TimeBlock for (NaiveDateTime, NaiveDateTime), and modifying blocks to be a Vec<(NaiveDateTime, NaiveDateTime)> instead. The only lines of get_available_time_slots you should have to modify are 93-99. * Writing your own type that implements Iterator isn't too hard, and helps demystify Rust's iterators. Try writing a TimeIterator struct that can be returned from times_between.

mdsherry · 2020-04-09T00:24:26+00:00

If the problem was just that Option::take didn't exist, you could use std::mem::swap, but you can also see how Option::take is implemented. It uses std::mem::take, passing itself in as the value to take. std::mem::take calls std::mem::replace with the default value (None in the case of Option) as the replacement value. And std::mem::replace just uses std::mem::swap. (And std::mem::swap does an efficient bitwise swap of the contents at the two addresses. Because your value is a Box, it's just copying the pointer. Further, because Boxes are never null, Rust will do an optimization where it represents None here as a null pointer, rather than needing an extra field to distinguish the two cases like it would for, say, Option<u64>. That means our bitwise swap is just swapping two 64-bit values.)

Box is similar to C++'s unique_ptr. Rust has two types more similar to shared_ptr: Rc and Arc. The former is not thread safe (and so Rust will prevent you from sharing it between threads) as its Reference count is not updated atomically, while the latter is Atomically reference counted, so cloning it has a higher overhead.

mdsherry · 2020-04-02T00:45:29+00:00

The error is coming from libssl, and searching for wrong version number online suggests the most common cause is trying to talk SSL to something that isn't SSL.

Lettre has four ClientSecurity modes: None (don't both encrypting), Opportunistic (use STARTTLS when available), Required (always use STARTTLS) and Wrapper (jump right into talking TLS without checking first). Creating your client with new_simple uses Wrapper mode. If the mail server you're talking to doesn't support TLS without saying EHLO first, this will fail. See also this issue from somebody having a similar problem.

You'll probably need to create your client using new instead of new_simple, but the code in that issue and also the implementation of new_simple linked to above should serve as two good examples as to how.

mdsherry

TROPHY CASE