TBF, if your step by steps instructions works, it doesn’t matter how complicated the command is.

Oh come on! I at least type the beginning so that it filters the history

Rust made me have an habit of using snake_case… .rs

Knowledge of your passwords

Uh… What password?

I kinda hate the push towards passkeys. If you have two factor Auth, going to passkeys makes you go back to 1 factor, aka less secured.

There’s also more and more 2FA fatigue attacks going on, and they can affect passkeys too, and if you don’t have a 2FA that involves the user writing a code on the 2FA device, passkeys could be quite possibly worse than passwords

TBH I thought it was for refactoring type safety. Making sure that the type is understood and not ready to just change wildly accidentally.

I do love rust. But I do like making fun of it too.

Although I don’t see how rust is immature? Unless I missed the joke?

I don’t get it either. OP might be angry at compile time (Couldn’t be worse than rust)

This is also part of my death, because it’s much easier to not deadlock when you are FIFO.

Personally I went for the nuclear option, and any transaction is sent as a tokio task to make sure the transaction keeps getting polled despite other futures getting polled. Coupled with a generous busy timeout timer (60secs) and Wal mode, it works pretty well.

Probably should also put the mutex strategy (perhaps a tokio semaphore instead?) although due to lifetimes it might be hard to make a begin() function on my DB pool wrapper.

… Congratulations. You nerd snipped me. Time for it to go on the todo stack.

Hyped for it too, but wouldn’t use until sqlx suport. Compile time checked queries are just so good. I don’t use rustsqlite for that reason alone (you often don’t need async SQLite anyways)

Tbh trigger performance isn’t that much of a concern unless you need to write lots of data, which most usage don’t need.

Also try check statements instead or even re-evaluate your schema to prevent them if you really need to.

Personally my death would be multiple write transaction deadlocks. Sadly it doesn’t play that well with async code, like with sqlx (rust).

I 100% agree… If you don’t need portable databases. For those, everybody like SQLite (even if it can be annoying sometimes)

You have rust:

You spent a lot of time planning and simulating the perfect rescue plan, and perform a blazingly fast 🔥🚀 and perfect rescue,

But you bore the princess to death explaining why she should stop being a princess and instead become a knight that rescue princesses.

I love rust btw, but the cultist behaviour needs to stop.

That’s the rust version

…

Looking back at the code (Sigh), it’s to prevent setting the CARGO variable to cargo mommy, and causing an infinite loop. You can still do cargo mommy mommy if you like double praises

That’s if the ai is learning from the responses. But there it’s more of a problem with the site not filtering data

That’s prepared statements, not AI generated.

… Although… It could be made, and sending the error could lead to a more personalized response. As well as being able to use character definitions from ai chat bots.

… Is it more cursed yet?

They didn’t even have mentioned the comments in the source code

/// Mommy intentionally lets her little ones call her recursively, since they might want to hear more from her~
///
/// If they call her a thousand times in a row, though, something has probably gone wrong 😏
const RECURSION_LIMIT: u8 = 100;
/// This name is intentionally not user-configurable. Mommy can't let the little ones make *too*
/// much of a mess~
const RECURSION_LIMIT_VAR: &str = "CARGO_MOMMY_RECURSION_LIMIT";

No need. It’s the best DB… Until you need something portable

Personally I don’t like unit tests. I’d rather have debug asserts and larger scope tests.

But using unit tests as debugging is near too

Ignoring the AI stuff, I don’t even get the joke.