I ran into the same issue not so long ago and at least for no_std I had to resort to using the async_trait crate. (The project is no_std but has alloc)
I can't recall the exact error so it might have been due to mixing async and non-async methods in the same trait. I would have to look at it again...
Its a fully electric drivetrain with a gas generator. When the battery runs low you can recharge it (even while driving) using the generator.
So you don't have the complexity of a combined hybrid drivetrain, but instead a normal BEV one plus a power generator, both of which are very well understood problems.
Another benefit is that the generator can always run at its most efficient rpm/power point and is decoupled from the speed of the wheels.
Interestingly Wankel engines have been making a bit of a comeback for this purpose since they can be built more compactly for the same output power.
A drawback compared to hybrid drivetrains is that both components need to be built for "full" load, whilst a hybrid drivetrain can combine powers to reach maximum performance, meaning each of the motors only has to carry half (or part) of the total load.
Just out of curiosity I don't see how 4 sticks die together at the exact same time unless the PSU is/has fucked up hard.
I'd argue that the likelihood of 4 sticks failing together is much lower than the MOBO or CPU or PSU failing in a way that makes RAM inaccessible.
Typically you'd see one stick failing at which point you could take it out and run with the other 3 (or 2 depending on configuration).
Anyway if you ever intend to return its probably best to keep the rest of the components because who knows which of those will be up next for a shortage/crisis.
I assume you mean AVIF? Because AV1 is not an image (file) format but a video compression format (that needs to be wrapped in container file formats to be storable).
I was under the impression that the compiler already optimizes out a lot of clones where the clone is primarily used to satisfy the borrow checker.
Is that not the case?
Looks a little grim but is quite funny. There's a demo available to test out.
I like that there is a vast amount of voice lines available for the game's characters to respond to whatever you typed in. It seems like the devs thought of nearly everything.
I ran into the same issue not so long ago and at least for
no_stdI had to resort to using theasync_traitcrate. (The project isno_stdbut hasalloc)I can't recall the exact error so it might have been due to mixing async and non-async methods in the same trait. I would have to look at it again...