Many editors can read config files from a file in the repository itself. And oftentimes it has the highest priority. Just gotta know the IDE of your target and they have to click “trust this project”.

unsafe fn<'a, T>(p: &'a T) -> &'static mut T {
    p as *cons T as *mut T as &'static mut T
}

It is a bit more than just dereferencing raw pointers.

Just ask your ISP for more upload speed (and pay for it). It’s a thing you can do.

Also, most importantly. Assembly.

JavaScript

Nonsense. Rust is clearly the superior blood type.

Well, to get a boolean out of a bit array you have to do some operations. So at first it doesn’t make it more performant. Compilers probably don’t automatically make them bitarrays because of that.

However, the memory savings means less cache used. And a cache miss is way more expensive than those bit operations. So they should be more performant. I’m sure someone out there has done the actual research and there’s a good reason why compilers don’t make all booleans bitarrays.

Don’t need sudo or anything pre installed for vscode either. It will send the server to the machine via SSH and then run it automagically.

You can do that with vscode too. And probably many IDEs.

The only real reason for which you would need to use vim in such cases is if the target computer can’t run the vscode server, which I’ve never encountered yet.

I guess that’s another way to avoid the overflow problem

C:

int increment(int i) {
    return (int) (1[(void*) i])

However, if you wanna go blazingly fast you gotta implement O(n) algorithms in rust. Additionally you want safety in case of integer overflows.

use std::error::Error;

#[derive(Debug, Error)]
struct IntegerOverflowError;

struct Incrementor {
    lookup_table: HashMap<i32, i33>
}

impl Incrementor {
    fn new() -> Self {
        let mut lut = HashMap::new();
        for i in 0..i32::MAX {
            lut.insert(i, i+1)
        }
        Incrementor { lookup_table: lut }
    }

    fn increment(&self, i: i32) -> Result<i32, IntegerOverflowError> {
        self.lookup_table.get(i)
            .map(|i| *i)
            .ok_or(IntegerOverflowError)
}

On mobile so I don’t even know if they compile though.

It is hard. Not everyone knows what colors are a problem for colorblind people. There are also many types of color blindness.

This user was not using git though, he was using vs code. That button doesn’t say “git reset” it says “discard all changes”. And btw, what it does is “git clean”, which is something that git can do.

Just below the button there is a list of all the changes. In his case, there were 3000 changes of the type “file creation”. Discarding a file creation can only be made one way: deleting the file.

Anyway, this user is presumably in his learning phase, I would not assume that he knows what git reset or git restore actually do.

There is a warning. IIRC it says “are you sure you want to discard all changes? This action is unreverisble”. In the context of version management. Creating a file is a change. And just below the button to discard all changes is the list of changes. In that list he could’ve seen 3000 changes of the type “file creation”, when you discard a file creation, it means to undo the creation, which is a deletion.

The button days what is going to do. There is a warning about what it’s going to do. And there is a list of the exact changes it’s going to undo.

The only way to avoid this from happening is to not have the button exist. In that case, the users that actually want to discard all changes would be unable to do so.

I don’t even know why people ITT are blaming the IDE and completely ignoring this.

When you learn git, you do so on a dummy project, that has 5 files which are 10 characters long each.

An IDE is not made so you can’t break things, it is tool, and it should let you do things. It’s like complaining that Linux will let you delete your desktop environment. Some people actually want to delete your desktop environment. You can’t remove that option just because someone can accidentally do it by ignoring all the warnings.

I have had many mouses. Most of them broke the side buttons. The scroll wheel usually lasts as much as the side buttons. After that. The left/right main buttons fail.

I have never had a mouse with a broken sensor though. I would look for solutions in the software (calibration and settings). But it’s not impossible that it’s broken.

The thing about UB is that many optimizations are possible precisely because the spec specified it as UB. And the spec did so in order to make these optimizations possible.

Codebases are not 6 lines long, they are hundreds of thousands. Without optimizations like those, many CPU cycles would be lost to unnecessary code being executed.

If you write C/C++, it is because you either hate yourself or the application’s performance is important, and these optimizations are needed.

The reason rust is so impressive nowadays is that you can write high performing code without risking accidentally doing UB. And if you are going to write code that might result in UB, you have to explicitly state so with unsafe. But for C/C++, there’s no saving. If you want your compiler to optimize code in those languages, you are going to have loaded guns pointing at your feet all the time.

I recently came across a rust book on how pointers aren’t just ints, because of UB.

fn main() {
    a = &1
    b = &2
    a++
    if a == b {
        *a = 3
        print(b)
    }
}

This may either: not print anything, print 3 or print 2.

Depending on the compiler, since b isn’t changed at all, it might optimize the print for print(2) instead of print(b). Even though everyone can agree that it should either not print anything or 3, but never 2.

If you want to use instructions from an extension (for example SIMD), you either: provide 2 versions of the function, or just won’t run in some CPUs. It would be weird for someone that doesn’t know about that to compile it for x86 and then have it not run on another x86 machine. I don’t think compilers use those instructions if you don’t tell them too.

Anyway, the SIMD the compilers will do is nowhere near the amount that it’s possible. If you manually use SIMD intrinsics/inline SIMD assembly, chances are that it will be faster than what the compiler would do. Especially because you are reducing the % of CPUs your program can run on.

The windows key is awesome though. It’s basically an “OS key”, since windows is not the only one that can use it, so the OS can have many hotkeys, all of them using the OS key, and it shouldn’t conflict with any program’s hotkeys. If any program uses the OS key for their default hotkey, that’s their problem.