Also Redis now includes the new Vector Sets data type that is not part of ValKey, and I'm right now working to a new data type that is not a niche use case as Vector Sets. So I expect them to diverge even more in the near future, and that certain use cases based on Redis or ValKey will be impossible to port easily to the other fork. But I believe this was unavoidable.
I remember Vector Sets - I helped Rowan with the vector-sets-browser. Exciting to see you back working on Redis. Would love to hear more about the new data type when you can share.
And yes, it is normal for different projects to take on different paths. All the more reason for specific tooling for both as well. I am trying to keep everything Redis compatible as much as possible too.
TLDR don't be an asshole and produce good stuff. But I have the feeling that this is not the right direction for the future. Distrust the process: only trust the results.
Moreover this policy is strictly unenforceable because good AI use is indistinguishable from good manual coding. And sometimes even the reverse. I don't believe in coding policies where maintainers need to spot if AI is used or not. I believe in experienced maintainers that are able to tell if a change looks sensible or not.
As someone who has picked up recently some 'legacy' code. AI has been really good at mostly summing up what is going on. In many cases it finds things I had no idea was wrong (because I do not know the code very well yet). This is so called 'battle hardened code'. I review it and say 'yeah its is wildly broken and I see how the original developer ended up here'. Sometimes the previous dev would be nice enough to leave a comment or some devs 'the code is the comments'. I have also had AI go wildly off the rails and do very dumb things. It is an interesting tool for sure one you have to keep an eye on or it will confidently make a foot gun for you. It is also nice for someone like me who has some sort of weird social anxiaty thing about bugging my fellow devs. In that I can create options tables and pick good ideas out of that.
I'm not sure I agree it's completely unenforceable: a sloppy, overly verbose PR, maybe without an attached issue, is pretty easy to pick out.
There's some sensible, easily-judged-by-a-human rules in here. I like the spirit of it and it's well written (I assume by Mitchell, not Claude, given the brevity).
This doesn't work in the age of AI where producing crappy results is much cheaper than verifying them. While this is the case, metadata will be important to understand if you should even bother verifying the results.
The time needed for an AI patch written with the prompt "now make it as small as possible, clean, and human coded" is as big as reviewing the patch itself.
If this were so, we wouldn’t be seeing such reactions from open source maintainers. The reality is AI makes it cheap to create large PRs with little substance.
I believe this is actually the center of the matter. Trump surely does not represents all the Americans, but I believe he is currently acting in a so aggressive way because America has a problem, that is: for years governments of other countries are selling more and more US bonds (because the United States look progressively less able to pay back), and given the US huge debt, this would mean an incredible problem for a country that for decades spent ways more than it was possible or wise (and, this spending also helped to fuel the IT strong position the country achieved). So, now, in order to have compelling arguments to ask for certain conditions, Trump is acting in this way, since in order to have something that others don't want to give to America, America needs to be a problem the other countries. This is a way to amplify your position in the world, that is otherwise not as strong as in the past. We used to watch Russia doing something like that, and could not expect to see this from USA. But things evolve...
1. Now it is much faster, and the Python benchmarks were re-done correctly (the benchmark didn't account for model loading, and did warm-up before starting the actual inference, while the C code was tested exactly in the reverse way).
2. Now there is --mmap support to run on Linux with blas target with 16GB of RAM. Inference is viable on my old-ish Dell Latitude i5.
Thanks, super interesting remarks. Funny enough I also went the route of implementing it backward :D Initially I totally skipped the text encoding part. Used Python to generate binary blogs. Also the easy 1 step test with image output correctness that you can implement immediately, with fixed seed and max pixel difference bound to floating point approximation errors, is super useful to provide the model with an immediate correctness feedback after a change.
I think that this is because the current code does a terrible job at taking the activations in the GPU and fusing the kernels. This is the next thing to fix in this implementation indeed.
Absolutely true, but now I'll focus on making it fast and I believe it will be possible to go much faster. I left the agent working in the night with a specification and now I'm going to see the progresses and restart the work.
reply