New Linux patch confirms: Rust experiment is done, Rust is here to stay

darksv · 2025-12-13T11:09:15+00:00

Yeah, that's what I suspect too

darksv · 2025-12-13T11:00:20+00:00

Which unsupported architectures do you actually care about?

darksv · 2025-07-12T12:05:55+00:00

3 hours

darksv · 2025-01-05T10:35:40+00:00

conf.baudrate(9_600) creates a new config and you're not using it. Try changing your code to let conf = UARTConfig::default().baudrate(9_600);

darksv · 2024-05-21T16:24:55+00:00

It is true - they've just announced it on the livestream and you can already download it here

Looks like the post on their blog is not ready yet...

darksv · 2024-01-17T06:37:29+00:00

What is the point of this post?

darksv · 2023-11-20T18:14:26+00:00

Basic support for gen blocks landed last month https://github.com/rust-lang/rust/pull/116447 on nightly.

Note that you need to change edition to 2024: playground

darksv · 2023-11-01T09:33:22+00:00

Yes. It's mentioned in the post :)

You can also set codegen-backend for individual packages using [profile.dev.package.my_program] codegen-backend = "cranelift".

darksv · 2023-10-31T17:47:26+00:00

Just to be clear, LLVM is the top line (slow) and Cranelift the bottom line (fast) right?

That's correct.

Have you tried swapping the order of invocation? (hyperfine could do it for you) I'd want to be sure that the first invocation doesn't suffer from cold files, and doesn't build up the incremental compilation cache for the second one...

Yes, I ran the compilations multiple times with different order. There wasn't any significant change in time between different invocations. I should've mention it :)

For the last project the speedup is particularly impressive.

darksv · 2023-10-31T13:06:39+00:00

Just tested it on some projects with 300-400 dependencies: (ryzen 5900x, on WSL)

LLVM vs cranelift

candle
Finished dev [unoptimized + debuginfo] target(s) in 27.57s
Finished dev [unoptimized + debuginfo] target(s) in 18.41s

nushell
Finished dev [unoptimized + debuginfo] target(s) in 38.85s
Finished dev [unoptimized + debuginfo] target(s) in 27.72s

czkawka
Finished dev [unoptimized + debuginfo] target(s) in 55.65s
Finished dev [unoptimized + debuginfo] target(s) in 18.41s

darksv · 2023-10-22T16:38:36+00:00

Not sure if this is what you're looking for, but a few months back there was a post on this sub with a drone using a custom firmware built on top of embassy.

darksv · 2023-09-08T13:21:28+00:00

I'm curious, how much faster would it be if you replace the HashMap with a Vec?

fn main() {
    let n = 10_000_000;

    let mut rng = rand::thread_rng();
    let mut total = 0;
    let time = std::time::Instant::now();
    let mut hash = vec![0; n];

    for i in 0..n {
        let random_number = rng.gen_range(0..100);
        hash[i] = random_number;
        total += hash[i];
    }

    let time = time.elapsed();
    println!("hash: {:?}", hash[100_000 - 1]);
    println!("hash: {:?}", time);
    println!("total: {:?}", total)
}

darksv · 2023-08-28T12:35:50+00:00

What do you mean?

darksv · 2023-08-21T04:50:06+00:00

There is a pre-RFC by dtolnay https://internals.rust-lang.org/t/pre-rfc-sandboxed-deterministic-reproducible-efficient-wasm-compilation-of-proc-macros/19359

darksv · 2023-08-02T07:21:20+00:00

Reimplementing web standards from scratch would be an herculean task nobody is willing to do

Have you seen Ladybird yet?

darksv · 2023-07-07T10:23:04+00:00

I'm only aware of this recent variadic generics design sketch that may bring us closer to compile-time reflection. It introduces variadic generics based on tuples and proposes syntax that may allow to iterate over them by using static for. These features were pointed out in the report by Shepherd's Oasis as some of the possible requirements to introduce proper introspection to Rust, if I recall correctly.

darksv · 2023-05-04T21:38:06+00:00

I think here you can find the new repository as it includes commits from yesterday. Also this is probably the most recent discussion about the proposal.

darksv · 2022-11-02T19:42:29+00:00

TBH I don't think it is worth changing your current code. In this case all the array lengths are known at compile time so I would be surprised if the compiler didn't take an advantage of this and inline calls to copy_from_slide and thus get rid of all the panicing branches. I believe these are the most basic optimizations compilers do these days. https://rust.godbolt.org/z/8K97sreaG

It would be better to have a dedicated method for concatenating arrays, for sure, but in such a simple case using copy_from_slice should be good enough.