See how i isn't 0 but the branch was still taken for no reason at all?

W H Y

Restart debugger if you made changes to the code, the ide might be out of sync

Note to self, let's not learn rust... or JavaScript or what ever rust pretends to not be.

Rust has some... Perverted... stuff.

The snippet of the code is pretty, but it's a small portion...

There might be a bug in Rust (possible)… It might be a scoping issue (even debugging tools can lie, rust is very complicated).... It can be a threading issue... Really. Anything.

Take a break, try to get a grasp of the bigger picture instead of the small portion that confuses you

@IntrusionCM Luckily it works now. Not that *that* wasn't an issue. Turns out I had a bug somewhere else...

I've also been programming for AVR for some time now and at some point you just stop caring about the insane shit that happens aslong as it works. JEZ jumps eventhough the register definitely isn't 0? Uhh.. add some sanity checks mabye it starts working again

@12bitfloat I usually tend to create a safety box with the last remaining pieces of my sanity when I hear the following stuff:

Asynchronous (aka Schrodinger's cat)…

Multithreaded (aka I've now made the problem occure less, but it's even less reasonable why)...

Master -/ Slave (aka we had to scale, but nobody thought about the consequences - it's worse then before, but even better: it has MULTIPLIED)

Everybody told us it is not possible, yet we did it anyway (not that is an applicable solution, rather a theoretical abomination that works under too specific circumstances).

Rust some how landed in this category too... Specifically because of the :it's so secure, you'll have to use unsecure to get a working program: TM.

Meeeh. I've gotten old and moody.

I've seen Ruby/Rails do something similar once before, too. Never did figure out why, but got a workaround in place.

It branched incorrectly on the same condition every single time. I inspected the vars, changed the condition order, did type coercion, etc. It wasn't something complex either; the logic was quite simple (two integer compares, and a string compare) and so was the surrounding method. No idea why it misbehaved, and was unable to reproduce it elsewhere. Haven't seen it since, either. Truly bizarre.

I've discovered flaws in a few other languages, too. (Qbasic, tibasic, vb, msvcpp (!), euphoria, gs2, javascript). Sometimes breaking things is really enjoyable 🙂

@Root That's awesome that you actually did find bugs. I normally rant about the amount of compiler bugs before I find my problem and realize that I am a god damn idiot

@12bitfloat 😅
I've done that many times too

literally me wondering why py3 can't figure out an "if <var> == 0:" but py2 can.

I'd hazard a guess at type mismatch... I'm sure I've done a rust tutorial that talks over something similar to this...
Or the variable is being changed by a different thread maybe?

"php is shit", "php is for idiots", "php has security flaws", "php doesn't worth shit"...

@ant0ny All singlethreaded and it's a comparsion between an u32 and an integer literal... It works now, i don't know what happened there :D

@KorDarei all of them are true tho ngl