the f

the fucking steam pipe has a leak on the valve because it's rusty

rust:

• r for "really good introduction game Half Life"
• u for "understandably, half life had DLC and sequels"
• s for "stay inside and play Half Life Alyx"
• t for "That means Half Life 3 is coming"

Hmm this one should work I think

https://www.youtube.com/watch?v=UthQ2gR1bU4

not available :(

https://www.youtube.com/watch?v=95qvqkf4EqE

i would simply have written my program in a language that had all the features i wanted.

exactly

Oh yeah. One of Rust's biggest problems is that very few batteries are included. (Even rand is a crate!) Big "can't break std's api if you don't have a std"

This isn't a blocker for anything I do but you are very right

oh my god

The one thing i find hard about rust is that most of the programs I write for my day to day use are things that basically just call linux system calls, or use popular C libraries, things that C++ is extremely good at. Or they're things that are trivial to do in python.

So as much as I like Rust, I don't actually know how to perform a sha256sum on a file and then set an xattr for it (without shelling out or downloading a random crate).

It's little things like that that keep it from being my go-to, but it's really good and I want to use it more.

was a bit confused as to why it's called volkswagen; it's a reference to the 2015 volkswagen emissions scandal. p amusing.

i will put down the pitchfork, for now

to reiterate what i said on the worst chat app in existence, you gotta do the TRUSTED_PROXIES=172.16.0.0/12 thing. this will make postmill accept caddy's x-forwarded-proto: https header that i'm pretty sure it sends to the backend. there is no need to edit the templates, as someone else suggested.

Thanks :)

my bad! i misread something earlier and thought this was fixed by someone else, i'll get to this soonish

also, props to astral.sh for uv (a rust-reimplementation of pip) and for taking in rye, which promises "Cargo for Python", something they blogged about eight years ago

(these are new, new, new, and currently a bit broken. i can't even get tqdm to install for some reason! their linter ruff is the only thing i would recommend using in a production environment.)

When learning new languages, I throw asserts all over the place. Learning to unit-test usually requires knowing more of the language than I already know, but asserts provide 90% of that value by forcing the code to crash if my mental-model of the code does not match reality.

I haven't even though about unit testing yet. I almost never unit test my utility scripts which is all I have built with it yet.

I also share these feelings!

It has that same magical "power" that functional languages have. I can put expressions in places that shouldn't be possible.

Working on a toy language, I threw an expression in curly braces, i.e. for x in {...}, which returned a different iterator depending on a condition. It really helped me cut down on code re-use (which was really good for my dev experience). That "clicked" in an extremely satisfying way.

that is also how i feel about it! i haven't had time to progress to a level where i can build "real" stuff with it but the few toy programs i've built were very satisfying. i also love the convention rust has for organizing the tests with the relevant code.

oh it's THAT kind of performance guru lol

thanks for the helpful comments everybody. i'm writing Elixir instead of C in this case, but that just goes to show that you can have this problem in any language with macros. i remember feeling this way about some lisp code in the past, too.

The DRY principle says that if you write something more than once you should refactor it. Here I see you used () in two places; that can be a macro, to ease readability.

OK so this is kind of a pain in the neck to do a lot of times but sometimes you can get the output if the C preprocessor.

Then through careful editing, you can kind of figure out what it's turning in to.

int main(...) {
   WEIRD_MACRO(1, 2);
}

Then you could just put comments above and below it, and run cpp -I/all/include/directories main.c

It will tell you the final output and also have debugging garbage about where each thing expanded from.

Not ideal, and also in a big project that uses a complex build tool it can be incredibly hard to get the cpp args, but it can help.

🚒 🚒 🚒 🚒 🚒

you should be writing everything in macros, as macros are fast

#define THE_PROGRAM all \
    your \
    code \
    goes \
    here

int main()
{
    THE_PROGRAM();
}