Silksong actually mentioned but only in a montage of 2025 games and it was one of the few without a specific date, lol

Right now, a lot of MUNYA

The video game that taught me how good video games could be. I still replay it every few years.

This change would also be bad for anything that scans for keywords, which includes most applicant tracking software.

I hate seeing data encoded into magic comments, struct tags included. One of my biggest gripes with Go is that I think they should have used a different symbol to distinguish important annotations from true comments.

Can we talk about how utterly absurd it is that there isn’t an obvious answer to this question yet? Feels like we’ve gone backwards from the AIM Direct Connect of old.

I always thought it was weird to model a game avatar after myself. I always roll the “random character” button (shout-out Monster Factory) when it’s available, keeps things simple.

In applications where I’ve needed this, I’ve taken a manual approach. Structure the function to return a single Result struct (including an error field), develop a convention for mapping function inputs to a string, then add reads & writes to a map[string]*Result which allows me to return cached values as a shortcut. No idea if it’s the most efficient way, I’ve not actually considered finding a package to handle the process.

Edit: For more advanced behavior, what are your thoughts on the official memoize package?

So, only about a decade until reaching feature parity with something like lazygit?

Interesting project but this write-up has a bizarre focus on number of lines of code, which doesn’t appear to differ substantially between the two approaches.

RE your edit: I also support that conclusion and I’m glad you’ll give it a shot yourself. A mindset that helps me is this: commenting is part of the iterative code writing process. When I’m struggling to put a concise and understandable comment above some code, it almost universally means that there’s something about the code itself I should arrange more clearly. This is your chance to do some rubber ducking, it’s valuable to both you and the next person to read your code!

Thanks for this, good reminder that there’s a lot of optimization I could do with my CI/CD build caching…

You joke but comic mono is startlingly easy to look at…

Overly fine-grained “brittle” mocks are something to be wary of, I agree that you don’t want to have to change a ton of tests every time you edit the code. But the hand-wavey suggestion of “use a fake instead” with no follow up is not particularly helpful…

That was a good write up of the loop var issue, I had run into that only once and figured it was just a part of the learning curve I hadn’t hit yet. Glad to see it’s an area everyone agreed could improve!

I could redraw this whole chart using only references to pipenv based on my experiences with managing it alongside other tools (especially homebrew). It’s good at many things but is no magic bullet.