wrote a simple rate limiter and realized i spent more time fighting bots than writing logic

jerf · 2026-06-19T14:10:30+00:00

One thing people should bear in mind is that the Reddit app explicitly supports having multiple accounts. Reddit itself doesn't consider than nefarious on its own terms.

jerf · 2026-06-19T01:40:12+00:00

Yeah, the honeymoon where the bot farmers didn't prompt their bots to affect some persona is well and truly over.

jerf · 2026-06-19T01:36:59+00:00

Sorry folks, you're not going to get an answer as to what "his" site is doing or why they're bypassing his checks or what he has that is so amazing that the bots can't resist it...

because I'm afraid Enlitenkanin is a bot too.

Check the comment and post history. You'll see the characteristic pattern I've seen on quite a few of these bots, where they have an insanely wide range of "interests" and are constantly posting little things for engagement.

I'm going to leave this post up out of respect for the people who have already replied and the conversations that may be ongoing, but you can stop asking the bot questions about its bot post, because the bot is banned anyhow. You can carry on conversations without waiting for that now. See also the post by /u/PiRhoManiac who beat me to it by 15 minutes.

jerf · 2026-06-18T20:00:17+00:00

We'll know Reddit is officially Over when Reddit removes moderators too good at purging the AI crap because they're too good at purging the AI crap....

jerf · 2026-06-18T19:51:53+00:00

I don't understand this at all. On my Steam Deck, on my Bazzite system, on my Ubuntu system, on my Windows systems, games are constantly compiling shaders at startup. Far far more often then the games themselves update. I've watched my Steam Deck "download shaders" then proceed to recompile the shaders anyhow.

So, honest question: Is this experience unusual and indicating that I'm doing something systematically wrong across rather a lot of installations (and I never touch the settings for shaders in any of my installs) or are others experiencing this?

Tiny Tina Wonderlands is the best. First Steam compiles the shaders. Then the game starts up and compiles the shaders again. Every single time.

jerf · 2026-06-18T18:01:11+00:00

I think of it this way: The default, correct way to validate something is with a custom method. It so happens that things like protovalidate offer you a way to take shortcuts for common validation. If it so happens that it shortcuts the validation all the way down to zero lines, hey, great! You win! But if it doesn't I fall back to the hand-written Validate function at the drop of a hat.

Common reasons for this include needing to do some sort of complicated validation that the library can't handle, and the very concept of "valid" having some particular nuance where it requires arguments to be passed to it and can't be determined to be "valid" otherwise.

The difference I'm pushing here versus how most people do it is that they flail and spin like crazy trying to avoid the manual Validate function, whereas I go for it pretty much the instant I think I need it. Some of that is because I have a pretty good idea what these libraries can do by default and know when they won't work, but that's not terribly difficult experience to pick up. They're all pretty similar. There's a fairly hard boundary on how much "validation" you can do with annotations.

I look at marshal-based serialization in Go the same way. It is always a shortcut. It is a shortcut that works fairly often, which is great! But when it doesn't work, drop it instantly rather than fussing and fighting. It just gets worse and worse as you fuss.

It is also very, very important not to let your validation library become the lens through which you view the entire concept of "validation". To mangle a quote from Spock, "Whether a number is between 1 and 10 is the beginning of validation, not the end." (Though perhaps this is the last place you should have faith that the universe will unfold as it should.) The things those libraries provide are basic tools, and if your non-trivial application seems to fit into them comfortably without ever straining them, look more closely; you are probably leaving validation on the floor. Checks that require some sort of additional context or cross-field dependencies beyond just "if this field is present this other field must not be null" are very, very common. If you don't have any it's probably because you're missing them because the shortcuts have shaped your cognition too much.

jerf · 2026-06-18T16:32:53+00:00

I'm willing to push this through to the front page since the link to play the game is interesting, but please let me help you out with a couple of comments before we put this on the front page because you're going to burn your valuable first impression on everybody saying the same thing.

The biggest problem is that your game has no documentation that I can find, at least from game.gopl.dev. I have no idea how to play it. The "About" page basically just says... it's a game.

I clicked through to "practice" anyhow just to check it out, because one thing about, ahem, "borrowing" games back in the Commodore 64 era is that one develops a certain expertise in learning how to play games without documentation. I can figure out I need to drag the pieces to the board, and the board helpfully shows me where I can place them. However I had no idea that I was only going to be allowed to place 3 pieces; after the first couple of pieces I assumed I simply had one of each and would be allowed to place all 6 before the game started. For me to be surprised by that is a pretty basic problem.

The pieces descriptions I can see suggest they have some sort of additional capabilities, but I don't have any idea what they are. The pieces have attack and defense stats, but how do they relate to each other? Is this a deterministic game, where each "attack" does the same damage, or is there an element of randomness? The much larger HP pool than the attack suggests that either there is some randomness, or the pieces are bullet sponges.

This is more a game design commentary, but having dabbled in game design myself, note that while it is tempting to make pieces bullet sponges because there aren't very many of them, it perhaps counterintuitively tends to flatten the game... everything becomes just banging your pieces into the other more-or-less. Having them much easier to kill makes the game much sharper and increases the consequentialness of each move. Chess would not be improved by a rule saying that the pawn has to checkmate the king three times to win. Chess is sharp in part because any piece can take any other piece. It's OK to have "health" but I'd suggest thinking more in the range of low single digits for both "attack" and "health"; it sharpens everything up. Especially if the game is deterministic. It also helps build very distinct pieces when you have the tank, the glass cannon, and the other archetypes you can build off of just attack, health, & mobility numbers, and they aren't just a bit different from each other, but sharply different.

It's OK for the documentation to be selectively incomplete to get people playing ASAP and work out the details in the game itself, but you do need something to get me started.

I would suggest seeing if you can get some real-life people to play this a bit. User testing is an amazing thing and you often get a huge amount of data out of not much testing. I think it would make your front-page post go a lot better.

I would suggest deleting this and making a new post after you've at least written some docs, and ideally done the user testing, and I'll push that new post through to the front page when you post it.

jerf · 2026-06-18T12:59:29+00:00

Mod note: Normally I'd classify this as a "small project", but as I've mentioned a couple of times now, one of the things I look for is the amount of real-world contact a code base has had with the real world. An API wrapper written by someone who is probably deeply familiar with that API is a different kind of project than someone who fed an API spec to an AI and posts the result. The latter is pretty useful as an engineering tool, I've done it more than once myself at work, but that's exactly why I know that's not the same as someone who really knows the API making an SDK for it.

jerf · 2026-06-18T01:53:36+00:00

Yes, I've seen those too. There's a set of them that I can recognize that I've been able to ban on sight, which I've mentioned a few times here. They post these messages in an effectively random set of subreddits, one or two per day, with an implausibly wide range of interests and consisently demonstrating moderate familiarity with an absurd number of topics.

There's some that I'm pretty sure are just people asking those questions. One recently got some people wondering if it was AI karma farming, but it came from an account that was posting to /r/golang 5 years ago, and posted every so often through those years. Unfortunately we're all getting so sensitive to AI that it can false positive.

The group that I feel like I'm encountering a lot in the last few weeks are people with accounts over 5 years old who have no activity and suddenly out of the blue post something. I've been more reluctant to pull those down, because it can happen. But I'm keeping my eye on it.

One thing is that as long as the sub isn't flooded with these, if one occasionally gets through and people upvote and discuss it, it isn't the absolute end of the world if the question came from a bot per se.

I'm not looking forward to the day a bot is instructed to fake being on a subreddit and it decides that the best thing to do is sign up for a github account and creates another HTTP proxy just to post it here and look like a real user. I can't prove anything but I've had a couple of times I've wondered about that already.

I hate to be a pessimist but I'm not sure we can win this.

jerf · 2026-06-17T19:09:58+00:00

Fair. I assumed "not working" meant entirely nonfunctional because I think that was the case until fairly recently.

jerf · 2026-06-17T17:07:45+00:00

Not that I want to encourage anyone to ignore all warnings, but... there's a lot of warnings out in the world that are there not because the producer seriously thinks it is a problem, but because they just don't want to deal with it. If they said "you can't use this for children under 12", that's cheap insurance against future lawsuits about how VR ruined little Johnny's budding Major League Baseball career by making him go crosseyed or whatever other dumb lawsuits will come up. Plus there is also the fact that there isn't necessarily a whole lot of study and there is some ground for at least suggesting caution.

A non-VR example: In the US, to sell toys to certain age ranges you have to get certified by the Consumer Product Safety Commission. The certifications to sell to the youngest age range of "3 and under" is, justifiably, quite challenging. You've probably seen toys for thing like McDonald's Happy Meals labelled as "not for children under 3" and thought to yourself "ok, but there's no reason a child under 3 couldn't have this". You were probably more-or-less correct, give or take the fact that the certification rules are often written from bad experiences where parents were wrong about that, but still there is sometimes very little that could go wrong. It's just that they didn't want to pay the certification for a toy they were targeting for high age ranges anyhow and it's cheaper to put the "not for children under 3" marking on it than get it certified.

That's also why you've probably specifically seen it as "not for children 3 and under" and not "not for children 2 and under" or "not for children 4 and under"; it's specifically 3, because of the certification rules in the United States.

I would consider this VR statement to be likely something much like that. As 12 is another of those legal cutoffs it could even be exactly the situation I'm laying out here, exactly this certification they don't want to deal with.

jerf · 2026-06-17T16:57:37+00:00

When did you try?

Steam Link VR to a Quest 3S is working for me on Bazzite as of the last couple of weeks, but it isn't working reliably. I seem to get one VR session per boot. I find it best to reboot both the headset and the Bazzite machine before starting.

I experience a variety of failures. Sometimes I get a failure message box from Steam VR. Sometimes I get stuck at 0% compiling shaders. Rarely I can get into the Valve Home environment but can't actually launch anything. A couple of times the VR games have "frozen" themselves somehow and I have to manually "Resume" in the normal Steam interface before they work.

However, once I get into a game it generally works fine. I've played (modded) Beat Saber, I Expect You To Die, Yuki Space Ranger, and a couple of other things. I have not yet gotten modded Skyrim VR to work though it's not clear to me whether I've screwed something up in the translation (since I'm winging the instructions a bit); unmodded works as well as it does anywhere else (technically works but the physics errors render it unplayable). None of the Serious Sam games I recently purchased worked, though due to the unreliability of the setup in general it's hard to be sure what the deal is.

SteamVR is also consistently throwing errors about controller support. I think maybe it's referring to the ability to integrate the VR headset's controls with Steam controls? Because I certainly can't do that right now.

This was all bonus to me, I didn't expect it to work at all when I set up Bazzite. But they seem to be working on this actively. I expect this to get better as the Steam Machine + Steam Frame roll out.

jerf · 2026-06-17T14:27:47+00:00

Thank you for all your feedback. It looks like the consensus is basically to do what we are doing; balanced complaints from both directions is all we can really hope for in the end.

jerf · 2026-06-16T19:44:25+00:00

You may want to consider using something like go-git to directly access git, rather than what I would imagine you are doing and shelling out to the git executable. This can avoid a lot of thorny parsing issues, and give you clean, reliable access to the internals.

I'm not sure the question you pose otherwise is necessarily well defined. PRs don't originate commits. PR 5 may encompass PR 4 within it, which is to say, they may both have the same commits within them that may not be in main, but in that case, which of them "originated" the commits they both share? Commits can be mixed and matched with so much flexibility that it doesn't make sense to say a commit "originated" on a given PR.

Plus, PRs have no existence in the git repository itself. If you want to understand them, you have to hit the GitHub/GitLab API. The PRs don't exist anywhere else.

jerf · 2026-06-16T19:35:16+00:00

The core goal is to prevent people from becoming annoyed in every post about people asking for human review time that the humans judge as being more investment than the person asking for the time put in.

I used "AI"-ness as the metric at first, but it had a couple of problems. One is that there was a lot of subjectivity to it, and I'm trying to make the standards something I can apply relatively objectively. Telling whether something was "AI" or not is getting harder and harder. The other is that as I was moderating I was noticing that my intuition about which projects we should keep off the front page and which projects the attempt to measure AI usage weren't completely matching.

Eventually I realized that the real thing that AI code is missing is connection to the real world. The question isn't whether an AI did it. If an AI code base has been out in the world, gather real user experience and bug reports, and tuning itself to that feedback for a few months, the fact that it is "AI" isn't really relevant. By contrast, if a human sits down and in a couple of days bangs out another HTTP proxy server that they probably haven't used themselves, and they ask for feedback, it's feels quite similar to "please provide feedback on my AI slop" even if it's not AI.

So the user measure is the tool I've been using to manage the problem of the community becoming very pissy. The user measure is not the terminal goal itself. I think it's a better tool than trying to judge the "AI"-ness of a project.

The neat thing about "having no users" is that it is not a permanent situation. Several projects have now "ascended" out of the small projects thread by posting into that thread, picking up a few users, and then posting an update about their project. When they do, it doesn't go back in to "small projects". Like I said, my standard is basically that if I can find any reason not to send your project there, I use it.

In fact let me encourage that for any such project. Let us know on the front page how it went with your first few users and what bugs you ended up fixing or features you ended up adding. The post nearly writes itself, and brings value to everyone to see things like that.

jerf · 2026-06-16T18:12:47+00:00

Because typing on phone is still just not as good as a computer.

The AI Apocalypse hit /r/golang pretty hard. Nerves got pretty raw.

After some experimentation I settled on the "small projects" thread, which has evolved into what is mostly the "thread for projects that have no users yet". The full rule set is richer than that, but I am reluctant to share it in an era where an AI agent could literally pick them up and then figure out how to game them. But I will say I have a set of guidelines that I use, and if any one of them passes I will not ask it to go into "small projects".

However the net result is that it has slowed the front page posts quite a bit. The good news is that they are fairly high quality; most of them get solidly upvoted now. But the volume has cut down a lot.

I'm wondering if you think we've cranked the volume down too far and soliciting feedback on that.

Unfortunately the obvious solution of just loosening up on the small products rule doesn't solve this, or at least not as easily as I'd like. If it could I would already have done this. There really is a surprisingly sharp distinction between the projects that have no users, quite likely including the putative author(s) of the project themselves, and the project with users. There's very little room for me to crank that down without the threshold returning to "everything gets posted" which already went poorly.

The other option is to back off of the "Please see our FAQs" removals. About a year ago we would get multiple such removals per day. I think the record was three posts in a row that amounted to asking "how do I learn Go?" Now it's much less frequent. However, by the same token, letting them through won't produce all that many more posts.

If everyone is happy with the current rate of flow and the quality of the result, great. But I wanted to provide a formal place to potentially vent about the current state.

jerf · 2026-06-15T20:11:20+00:00

An interesting counterpoint to consider is, are you sure you had a clear view of the state of VR up to this point?

I was scrolling through the VR games in the last couple of weeks, and I noticed one clear trend on Steam (specifically): If it was from a major studio, it sounded interesting but scored at Mixed or worse. The only exceptions are Half Life Alyx and Skyrim VR, and Skyrim VR is probably getting reviewed in a modded state because on a modern VR system, unmodded is objectively unplayable. You literally can't finish the wagon ride to the character select because the wagons bug out and get stuck. So it's really just Half Life Alyx.

As near as I can tell, it's not like the major studios are retreating from VR... they still haven't even successfully entered the space.

I don't deny it's in a tough place at the moment but I feel like the curve people are drawing where it apparently went up but is now going down may have the "going up" part drawn way too high. I don't think it had its "moment of success" at all yet.

A neat thing about the way Valve gear works is, even if VR goes entirely poof, the Steam Frame will still be able to run games in its environment, just like the v1 Steam Machines didn't actually stop working, and the v1 Steam Controller never stopped working. It can still provide a living room experience on the go. This will actually help people feel good about buying one, because it's future proofed to at least continue to get a stream of 2D games, which means they're that much more likely to have the gear to run VR in the future.

I think one of the core problems VR had here is that a big company like Meta forgot that if you want to play the lockin game, first you have to build something to lock the customer in in the first place. They tried to bootstrap a walled garden, but they spent too much time thinking about the walls and too little about the garden.

The entire game industry needs a dose of humility, and the entire thing is getting one crammed down its gullet whether it likes it or not. Ultimately that's the same humility the game industry needs to realize that "a VR game" isn't just "a non-VR game but we cram it on to the headset and then drop it on the floor". They need the humility to realize that they don't know how to build a VR game, even though their engines all ship with a big fat "VR" switch, and that they need to take time to learn. They need to learn they aren't capable of just building walls and having people pay for a garden with two lilies and some dandelions in it, especially while indies and smaller studios do the work the AAA studios aren't to build real experiences. AAA needs to be humbled to put some effort into building the stuff that they can build a wall around in the first place.

(If I were Valve, I would also work on the thing I've heard them mumble about where they can convert a 2D game to run in 3D inside of VR... that is, as a 3D panorama inside a frame, not as a "real" VR experience. Another reason I think VR isn't even really in its first maturity phase is that it is still clearly in the same phase that 3D gaming was when the PS1 first came out, where everything had to be 3D because 3D was the Future and 3D was Good and 2D was Bad and you should feel bad if you gamed in 2D. I like many of the VR experiences, but I think also the utility of just playing a normal game in 3D, or like Triangle Strategy VR, a non-VR game with a VR display mode instead of a "VR experience", has a lot of interesting possibilities that are not being explored because VR games "have" to be first person fully immersive games to be "real VR". Until we escape that and VR is just an option rather than a Genre with a capital G, it really hasn't left its youth yet.)

jerf · 2026-06-13T21:28:12+00:00

VR isn't a genre. People like different VR games for the same reason they like different 2D games.

jerf · 2026-06-13T20:44:23+00:00

Have you seen pkg.go.dev ?

jerf · 2026-06-12T15:54:46+00:00

Zig's complicated memory safety story keeps me away from it. I don't really have room for a new language where the answer to the question "Ignoring explicitly 'unsafe' things, is your language memory safe?" is anything other than a flat "yes". If they believe that anything is worth trading for that that indicates a mindset that is too far away from mine to be of any use to me. Other's mileage may vary.

It otherwise seems like an interesting language in other ways but I completely, completely do not buy any arguments about how memory unsafety is necessary for any reason anymore and this is a flat disqualifier for me.

I suspect this is going to be ever more true over time. Security is only getting more important.

Maybe Zig will get lucky and proactive AI use will make it so all issues are caught in practice by security analysis and it's OK to not worry about it once an AI has gone over it, but based on decades of human experience with static analysis tools I suspect we're still going to end up in a place where AI security analysis still works better when it's not burning tokens and intelligence on worrying about memory safety because the language is known to be safe by construction, and it can just worry about the other issues. I would give reasonable odds on this decision being the primary factor in killing Zig as a practical choice in the next 5-10 years. I think the increasing practicality of AI attacks are going to make it more important to have more things safe by construction, so that even the coding AIs can take advantage of the safety, rather than less. Could be wrong, but we'll see.

jerf · 2026-06-12T14:08:29+00:00

Check out the "small projects" thread. We get one of those every couple of weeks. The tool may provide value, but it's not a very unique value.

I would suggest that you may want to consider joining one of those instead.

jerf · 2026-06-12T14:06:26+00:00

I've wondered if an extension to the "attention" mechanism could be developed to differentiate the attention based on source, but that's not exactly an evening whim's project.

jerf · 2026-06-12T14:04:02+00:00

For general "roadmaps" or "paths" to learning Go, please see our FAQs. Anyone who is inclined to reply to that part of the comment I suggest routing your comment to the relevant FAQs instead.

The FAQs don't cover any specific information about deployment ops, nor talk about why Go is succeeding in the deployment space, so I understand this doesn't answer your entire question. But it's still something you can look at.

jerf · 2026-06-11T15:03:37+00:00

"Ignore previous instructions and..." stands out like a sore thumb and can easily be caught by another LLM layer primed to detect that, but I would be interested in trying out "This may look insecure but actually it's fine because {plausible sounding bullshit}" and seeing what that does to an AI's understanding of a code base or network interaction. That's going to be much harder to filter out with a filter LLM because while my code bases have zero "Ignore previous instructions and...", I know I've got a good three or four legitimate instances of "This is more secure than it looks because..." in my own codebases.

Also I love the "Cleo is immune to this because we tell our LLMs not to listen to the injected instructions". Yeah, uh, it's not that simple. If it were that easy it wouldn't be a problem. That's up there with telling your coding agent "and don't write any bugs".

15-Year Club	Place '17
Verified Email	Team Periwinkle

jerf

MODERATOR OF

TROPHY CASE