r/rust

Hi everyone 👋

First of all, I want to thank you all for your support throughout my journey learning Rust and working on my Rust embedded vector database, . Really appreciate the feedback, suggestions, and most importantly contributions that this community give me.

Since about 1 month ago, I was starting to feel the burnout doing just open-source because my savings is running out and stress from life in general. I love doing open-source and supporting people using OasysDB but without a full-time job to support myself, its not maintainable in the long-term.

Also, hearing the story about xz and stuff, I'm glad that people in OasysDB community is very patient and supportive.

So, long story short, someone opened an issue on OasysDB and suggested me to integrate OasysDB with his platform, , an open-source infrastracture for real-time data extraction and processing for gen AI apps.

We connected via LinkedIn and he noticed that I have my #OpenToWork badge on and asked me about it. I told him that if he's hiring, I'd love to be in his team. And he was!

We chat for the following day and the day after discussing the projects, the motivation behind them, and stuff.

The whole process went by really fast. He made the decision to onboard me the same day we last had a chat, Friday last week. We discuss the detail of the job and compensation over the weekend and just like that, I got my first Rust-oriented job.

I hear somewhere that to get lucky, you need to spread the area where you can receive luck. For me, my open-source project, OasysDB, is one such area.

If you are still trying to find a job, don’t give up and consider different channels other than applying via job boards.

Anyway, If you have any questions, please feel free to ask and if you have similar story, I'd love to hear them too 😁

I've recently tuned in to one of Jon Gjenset's recent where he discusses the occasional over-reliance on mpsc queues in fan-in situations (i.e., multiple workers emitting events through a single consumer). One alternative he mentions is instead relying on Arc<Mutex<Vec<T>>>> as where:

• Workers can extend the buffer with data

• Actor can swap the buffer with an empty buffer and process the current buffer, allowing critical zone to be exceptionally small

I tried giving this a shot. We have a serial actor/worker with no internal buffering.

pub async fn serial_actor(mut rx: tokio::sync::mpsc::UnboundedReceiver<u8>, samples: u64) {
    let mut iters = 0;

    while iters < samples {
        let _ = rx.recv().await;
        iters += 1;
    }
}

Alternatively a similar scenario but passing a buffer around:

pub async fn mutex_actor(buf: Arc<Mutex<Vec<u8>>>, samples: u64) {
    let mut iters = 0;

    while iters < samples {
        let mut current = buf.lock().await;

        // Swap the buffer with an empty one.
        let mut buffer = Vec::with_capacity(current.capacity());
        std::mem::swap(&mut buffer, &mut *current);
        drop(current);

        iters += 1;
    }
}

I ran a few parameterised with 1, 4, 8, 16, 32, 64, 128, 256, 512 and 1024 workers, sending 100,000 messages per worker. The results were interesting:

Where (a) the mpsc implementation performs ≈2x better in all conditions and (b) the performance is linear (initially thought contention would affect the results differently).

Am I missing the point highlighted during the stream, or not reflecting is correctly in the benchmark?

One final data point: when testing both clients against a stub , the mutex implementation performed a lot faster in terms of processes 10M messages. That said it's difficult to repllicate and want to avoid local I/O as a cause.

Is there a stable and complete http server written in rust and have the functionnalities of Apache and Nginx (reverse proxy,...) that can be installed in windows and linux?

Thanks

I wanted <[T]>::first to be infallible, but to otherwise use other methods like <[_]>::rotate, which existing crates like can't do (without breaking their API).

So I've written , with the following highlights:
- I scraped the rustdoc for std to provide a complete API. With few exceptions, for every Vec<T> -> Box<[T]> there is a NonEmpty<Vec<T>> -> Box<NonEmpty<[T]>>
- Support for exotic types like Cows and boxed slices.
- #[repr(transparent)] gives you flexibility to go from &[u8] -> &NonEmpty<[u8]>
- const and no_std/no-alloc friendly
- extensive support for external libraries like serde, arbitrary and schemars

I'd be interested to hear your thoughts on:
- API noise - is having a a single NonEmpty<T> struct overrated? It leaves the a little noisy...
- Sharp edges - are there impls you wished existed?
- External traits that should be feature gated and implemented
- Can you think of a better name for the crate? I don't like nunny, but nonempty was taken :D

Thanks!

| |

Is it yet possible to write entire programs (in a language like, say, Rust) and build them to run on Wasmtime (by that, I mean any kind of program, including desktop GUI ones).

So that you compile once for Wasm and can run on any system with Wasmtime without recompilation, as long as you've included in your compiled wasm code all the requisite dependencies too. Same concept as the JVM.

Is that possible yet?

I am going through the Rust Book and on this , it is discussing closures with the following code example:

#[derive(Debug, PartialEq, Copy, Clone)]
enum ShirtColor {
    Red,
    Blue,
}

struct Inventory {
    shirts: Vec<ShirtColor>,
}

impl Inventory {
    fn giveaway(&self, user_preference: Option<ShirtColor>) -> ShirtColor {
        // Book uses this example
        //user_preference.unwrap_or_else(|| self.most_stocked())

        // This presents same result
        match user_preference {
            Some(x) => return x,
            None => return self.most_stocked(),
        }
    }

    fn most_stocked(&self) -> ShirtColor {
        let mut num_red = 0;
        let mut num_blue = 0;

        for color in &self.shirts {
            match color {
                ShirtColor::Red => num_red += 1,
                ShirtColor::Blue => num_blue += 1,
            }
        }
        if num_red > num_blue {
            ShirtColor::Red
        } else {
            ShirtColor::Blue
        }
    }
}
fn main() {
    let store = Inventory {
        shirts: vec![ShirtColor::Blue, ShirtColor::Red, ShirtColor::Blue],
    };

    let user_pref1 = Some(ShirtColor::Red);
    let giveaway1 = store.giveaway(user_pref1);
    println!(
        "The user with preference {:?} gets {:?}",
        user_pref1, giveaway1
    );

    let user_pref2 = None;
    let giveaway2 = store.giveaway(user_pref2);
    println!(
        "The user with preference {:?} gets {:?}",
        user_pref2, giveaway2
    );
}

So in the function giveaway it is using a closure within unwrap_or_else(|| self.most_stocked()). What "environment" is being captured here that a closure has an advantage of over instead of just the approach I took with the match? To me it seems that the closure is just providing a more succinct code, but am not seeing the advantage explained in the book:

One interesting aspect here is that we’ve passed a closure that calls self.most_stocked() on the current Inventory instance. The standard library didn’t need to know anything about the Inventory or ShirtColor types we defined, or the logic we want to use in this scenario. The closure captures an immutable reference to the self Inventory instance and passes it with the code we specify to the unwrap_or_else method. Functions, on the other hand, are not able to capture their environment in this way.

Sorry if this is a silly question, but trying to grasp the advantage of closures over just shorter code. :)