Of the codebases i know that have adopted Rust, it has always been because some of their maintainers wanted to do so.
Maybe git's case is different though. Do you have more info about it? Are you a git maintainer who was coerced to use Rust, or do you know of such cases?
> It’s astonishing to me that we have to spell this out, that something as obvious as this needs to be explained to LLM’s at all.
Hehe. Yeah, that tendency of LLMs to document "the story" of the code instead of its current purpose (or non-obvious implementation details) is a pet peeve of mine too. I've added a slew of guidelines to try to sway Claude to not do this, but it still does it often.
At the same time, it feels like something to be expected to have this "failure mode". The model has its context to work on, and what is on its context if not the conversation you've been having (and its internal monologue) and the files it has read? It makes sense that it references the story on its text generations, because that behavior is usually a good thing for an LLM to do. Otherwise, what would it generate? If it generated things that had nothing to do with the conversation in its context, in many cases those things would be seen as "hallucinations", and they'd tend to be RLHF'ed out. So the models that we end up having are the ones that have been reinforced to be most "contextually relevant" and less "hallucinatory".
I might be completely wrong on that of course. It's just my intuitive reasoning of why this seems to be such a prevalent behavior.
RLHF has the same problem as human reviews of AI code: AI code (and comments) look plausible at first, and if you have 100 other PR's to get to, it looks "good enough" and you approve it. I'm sure the humans doing the "human feedback" part of RLHF at anthropic are just as tired as I am at reading all of it, and start to just approve it when it looks plausible.
It's doubly insidious because it trips up the human brain too: When I'm reading a PR saying "fix lock ordering to avoid deadlocks on user deletion", and there's a comment somewhere in the diff saying "// use the fixed lock ordering here", my brain tends to completely forget the fact that the comment doesn't make any sense in its surrounding context. Because it makes perfect sense in the context of being the human reviewing the diff. But it's a slight bit of mental effort to remind yourself "what is this comment going to look like to someone reading the code after this is merged?"
I wouldn't be surprised whatsoever if the RLHF supervisors forget to apply that extra bit of mental effort and say "yup, this comment looks great", forgetting to check the surrounding code to see if it makes sense on its own.
Do you think an LLM would be able to generate a solution to a novel problem just like that?
That doesn't match my (albeit limited) experience with these things. They are pretty good at other things, but generally squarely in the real of "already done" things.
Anti-crawler tarpits and related concepts have existed for decades already; LLM training data is only the latest and most popular of web-scraping goals.
Claude is happy and able to provide a laundry list of ways to mitigate the impact of tarpits on your crawler, and politeness / respecting robots.txt is only one of them.
Five years ago, we could've read this same comment but with "LLMs" replaced with "blockchain" or "crypto".
Yes, it might totally be the case that in 5 years this comment reads as correctly predicting the future that is to come. But it's also possible that it doesn't.
It's not at all clear to me which things will persist in time at the moment they are getting popular. There are lots of technologies that look promising in the beginning and up fizzling out.
Browsers are useful now, and they have been useful for a while. It seems to me like a safer bet to invest on them still doing what they are useful at, in the case that the web keeps being a thing for a while still :)
oh, 100% yes! The job project i joined somewhat recently is a moderately-complex React web app, and none of the navigation elements are actual links. Everything is done by onClick handling, even thought many things are, conceptually, just links. I have no idea why this kind of thing is so widespread on the web front-end world.
> You need to kneel to the borrow-checker and develop something like a Stockholm syndrome before you find the language delicious.
That was not my experience at all. I liked the language from the get-go. And the more i dug into it, the more i found to like. I really appreciated the design of Rust's iterators, and traits, and general language design, way before i stumbled into any major issues with the borrow checker.
I feel like this depends very much on the programming style and probably on the domain. But i found that programming in a mostly "functions and simple data structures" way, passing things down to other functions that need them, and just processing data instead of "modeling the domain" into mutable and confusing "objects", i didn't really come across many lifetime-related issues that the borrow checker warns about.
And the few that i did found, they were actually errors on my part, and Rust detecting them was quite helpful. Things like trying to mutate a collection while also iterating it.
OOP has many short comings (enough that I would say it has been the single worst design paradigm that afflicted this industry), so Rust felt like a breath of fresh air to a c++ dev. However, many basic patterns that are employed when you are building embedded software are just needlessly difficult. Zig is the better C, and it’s just the better language for getting stuff done with total control. If I need to be high level with more I’ll reach for something else (c# provides all the optimisations I need if I’m not bit bashing). Rust feels like it has this one great trick, no gc and memory safety, but nothing else to offer.
> What inspired you to build this, I'd love to hear the story behind this.
Actually, i don't remember! Sorry, it's been a while (a decade, it seems... oh well)
This is probably my mind retro-creating a story, but i think this started with me wondering about how the Braille system worked. Like, did each Braille symbol map to a single letter, or to a whole syllable, or even a concept? Or, were more than one Braille symbol needed for some letters, like Morse?
Turns out each Braille symbol fits within a 2x4 grid of points. That's 2 possible states (point is on or off) for each of those 8 points. So 2^8 = 256 possible values. That's a byte! And luckily, Unicode encodes all those 256 possible values, and maps them to codepoints in a very systematic way.
So obviously, i started to wonder what kind of things could be represented on these Braille grids. The snake game was a natural fit, and a fun programming experience. But i also considered other things, like a horizontal Tetris. Or a Game of Life rendered on the URL, which i actually implemented(1), but i didn't find as entertaining as snake, because the 4-tile height restriction impeded any interesting patterns, like gliders (even with wrap-around logic). I think i even made some brute-force searching for horizontal or diagonal gliders trying out different born/survive rules(2), but couldn't find any interesting patterns, other than still life, blinkers, and some "moving walls" kind of things.
Anyways, that's for the Braille part. The idea of using the address bar to render the game, i have no idea where that came from TBH. Maybe i stole the idea from some other animated or pretty thing on URLs? I wish i remembered.
Yeah, sorry for that. The game actually used to work decently well on mobile browsers.
If you're brave enough to try on a mobile device, there's a way to see the current URL without escaping on the page: clicking on that "?". The mobile controls are clunky, but you'll be rewarded with the ability to share your highscores with friends! :P
Maybe git's case is different though. Do you have more info about it? Are you a git maintainer who was coerced to use Rust, or do you know of such cases?