I've used a number of different Linux distros (including Debian) on laptops over the years. Although most recently my XPS 15 was running Arch.
nick
*rate, comment, and subscribe
Gotta get those five stars
I think they're lawful evil, more devils than demons.
In my experience I haven't had an issue because usually the refactorings are small. If they're not I just hop on a call with the person who wrote the MR and ask them to walk me through it.
In theory I'd like to have time to dedicate solely to code health, but that's not quite the situation in basically any team I've been in.
You should refactor as needed as you go because refactoring cases are never gonna be prioritised.
There's a markdown entry thing in the drop down menu that'll convert your MD to their formatting.
The web is built on hot linking hypermedia. It is more fragile obviously, but it distributes the bandwidth and storage load. If nobody hotlinked, then small forum admins/Lemmy admins/etc. have considerably more cost to bear.
Rust is roughly similar to C in most of these benchmarks and beats it in a few: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
Arguably when LLVM gets a bit better, Rust can be even faster than C because rust can be optimised in more places safely than C code can. The issue is that LLVM wasn't written with that in mind, so some performance is left on the table.
Go, Java, and Nim (in most cases) are all memory safe but are generally slower than C or C++ due to the ways they achieve memory safety.
Rust's memory safety approach is zero-cost performance wise, which makes it practical for low level, high throughput, and low latency applications.
That flag exists, it's called unsafe
for if you need to tell the borrow checker to trust you or unwrap
if you don't want to deal with handling errors on most ADTs.
You can always cast anything to an unmanaged pointer type and use it in unsafe code.
A crash is different to a SEGFAULT. I'd be very surprised to see a safe rust program segfault unless it was actively exploiting a compiler bug.
This reminds me of a great video about this sort of principle in reverse: https://youtu.be/wBBnfu8N_J0