- ITT people defending a megacorp. Oh my...
- > why not just move to treating linux as the first class platform
This is where the argument goes back to Win32 is the most stable API in Linux land. There isn't a thing such as the Linux API so that would have to be invented first. Try running an application that was built for Ubuntu 16.04 LTS on Ubuntu 24.04 LTS. Good luck with that. Don't get me wrong, I primarily use and love Linux, but reality is quite complicated.
- Why use an extra tool, when you can tell the LLM where the Godot source is to be found in case it wants to investigate some details? What is the benefit of using repomix?
- How well has your vibecoding with Godot worked? I thought about it but wouldn't the LLM be unable to add files by itself due to stuff only the Godot editor knows how to do like generating uid files and so on? I would have expected that the LLM needs a MCP or some tool calling to properly interact with a Godot project. How are you doing it?
- Just curious, wouldn't it be easier to download the docs in a format that is searchable for the LLM? A MCP for this seems overkill to me.
- Hi! Cool to see you commenting here, great work on gdzig btw :)
- I know, it's the title of their own post, but making it sound like pixi is only for robotics is underselling pixi quite heavily.
Pixi is basically uv but for the conda ecosystem in the sense that it has all the goodness (fast and reliable dependency solver, smart caching, using hardlinks for environment installs to speed things up and save space) and makes the whole environment/dependency management for conda project so much faster and more robust. For dependencies from PyPI, pixi uses the uv crate under the hood, so it doesn't waste effort on that front and works just as well.
I think many python project will be fine with just using uv but at least for my use case, pixi turned out to be just what I needed, because my software also needs to run on older macOS versions, Intel and Arm Macs, and packages like OpenCV or PyTorch are just not officially built for those anymore, but in the conda ecosystem, there are countless brave souls who build this stuff for macOS 11+ so I can just use that and it's such a relief.
Uv is getting most of the attention right now and I can totally understand why, but if python is your main thing and you want to keep up with what's the best the ecosystem can offer right now, you should at least give pixi a try and evaluate the pros and cons yourself. It's really worth it imo.
- Can you please provide a source? I'd love to know their exact reasoning and/or evidence that XML is the way to go.
- Thanks for the reply, that part about the models attention is pretty interesting!
I would suspect that a single attention layer won't be able to figure out to which token a token for an opening bracket should attend the most to. Think of {"x": {y: 1}} so with only one layer of attention, can the token for the first opening bracket successfully attend to exactly the matching closing bracket?
I wonder if RNNs work better with JSON or XML. Or maybe they are just fine with both of them because a RNN can have some stack-like internal state that can match brackets?
Probably, it would be a really cool research direction to measure how well Transformer-Mamba hybrid models like Jamba perform on structured input/output formats like JSON and XML and compare them. For the LLM era, I could only find papers that do this evaluation with transformer-based LLMs. Damn, I'd love to work at a place that does this kind of research, but guess I'm stuck with my current boring job now :D Born to do cutting-edge research, forced to write CRUD apps with some "AI sprinkled in". Anyone hiring here?
- I'd be really interested in what you mean. Are the any studies that quantify this difference in model performance when using JSON or XML? What could be a good intuition for why there might be a big difference? If XML is better than JSON for LLMs, why isn't everyone and the grandma recommending me to use XML instead of JSON? Why is Google Gemini API offering structured output only with JSON schema instead of XML schema?
- > /Looks around all innocent ... does 57 billion count?
That surely counts as a case where brute-force search will not do :) I'm intrigued though, do you really need to make searches over all those vectors or could you filter the candidates down to something <5M ? As I wrote, this is one of the nice advantages of no-index brute-force search, you can use good 'ol SQL WHERE clauses to limit the amount of candidates in many cases and then the brute-force search is not as expensive. Complex indices like HNSW or DiskANN don't play as nice with filters.
- How's a database being columnar irrelevant to vector search? This very vector search extension shows that brute force search can work surprisingly well up to a certain dataset size and at this point columnar storage is great because it gives a perfect memory access pattern for the vector search instead of iterating over all the rows of a table and only accessing the vector of a row.
- Sorry for not being on topic, just wanted to say hi @mholt and for making and maintaining Caddy! Happy Caddy user here.
- It's unfortunate that this one is not really open source, it has Elastic License 2.0 license.
But it's still a wonderful example for how far you can get with brute-force vector similarity search that has been optimized like crazy by making use of SIMD. Not having to use a fancy index is such a blessing. Think of all the complexities that you don't have when not using an index. You don't have these additional worries about memory and/or disk usage or insert/delete/update costs and you can make full use of SQL filters. It's crazy to me what kind of vector DBs people put up with. They use custom query languages, have to hold huge indices in memory or write humongous indices to disk for something that's not necessarily faster than brute-force search for tables with <5M rows. And let's be honest who has those gigantic tables with more than 5M rows? Not too many I'd assume.
- Okay, bummer. No support for quantized datatypes yet and from the docs I cannot see anything that mentions fast brute force search. I personally don't need an index. But I see that https://github.com/unum-cloud/usearch which is used by duckdb-vss in turn uses https://github.com/ashvardanian/simsimd which should make a really fast exact vector similarity search possible. Am I missing something here?
- I'd be cautious. Project seems abandoned. And I wouldn't say it's one of those cases where a piece of software is just finished and doesn't need any changes.
- Oh right, duckdb being columnar is the ultimate brrr factor for such a brute force vector similarity search. But doesn't using a HNSW index completely forfeit this potential advantage?
- > Or we could, you know, do the hard work and build better programming languages, compilers, and libraries. But that can’t be hyped up for billions.
100% this. I fear that AI will cause us to be stuck in a local optimum for the next decades where most of the code will be Python or JS because these are the languages best supported by LLMs. Don't get me wrong, Python and JS and mature and productive languages. That's fine. But we could have it so much better if there was more effort put into a next generation of tools that take all the harsh lessons learnt from the tools before and "just" do it better. I acknowledge that we get incremental improvements here and there but some things are just unfixable without breaking existing ecosystems.
- Damn, you're right. That's a deal breaker for me at least.
- I think the whole field of vector databases is mostly just one huge misunderstanding. Most of you are not Google or any other big tech company so so won't have billions of embeddings.
It's crazy how people add bloat and complexity to their stuff just because they want to do medium scale RAG with ca. 2 million embeddings.
Here comes the punchline, you do not need a fancy vector database in this case. I stumbled over https://github.com/sqliteai/sqlite-vector which is a SQLite extension and I wonder why no one else did this before, but it simply implements a highly optimized brute force search over the vectors, so you get sub 100ms queries over millions of vectors with perfect recall. It uses dynamic runtime dispatch that makes use of the available SIMD instructions your CPU has. Turns out this might be all you need. No need for memory a memory hungry search index (like HNSW) or writing a huge index to disk (like DiskANN).
- Thanks for pointing that out. And yeah, with how Zig is evolving over time, it's a tough task for LLMs. But one would imagine that it should be no problem giving the LLM access to the Zig docs and it will figure out things on its own. But I'm not seeing such stories, maybe I have to keep looking.
- (user name checks out, nice)
I share similar feelings. I don't want to shit on Python and JS/TS. Those are languages that get stuff done, but they are a local optimum at best. I don't want the whole field to get stuck with what we have today. There surely is place for a new programming language that will be so much better that we will scratch our heads why we ever stuck with what we have today. But when LLMs work "good enough" why even invent a new programming language? And even if that awesome language exists today, why adopt it then? It's frustrating to think about. Even language tooling like static analyzers and linters might get less love now. Although I'm cautiously optimistic, as these tools can feed into LLMs and thus improve how they work. So at least there is an incentive.
- Yup. The frustrating thing is that I already read tons of material on how to "hold it right", for example [Agentic Engineering in Action with Mitchell Hashimoto](https://www.youtube.com/watch?v=XyQ4ZTS5dGw) and other stuff, but in my personal experience it just does not work. Maybe the things I want to work on are too niche? But to be fair, that example from Mitchell Hashimoto is working with zig, which is for LLM standards very niche so I dunno man.
Really, someone, just show me how you vibecode that seemlingly simple feature https://github.com/JaneySprings/DotRush/issues/89 without having some deep knowledge of the codebase. As of now, I don't believe this works.
- I have no problem with the amount of money that is dumped into AI, but I'm annoyed by the false promises. People telling me that Claude Code has no problem implementing clearly defined little feature requests but when I let it tackle this one here https://github.com/JaneySprings/DotRush/issues/89 (add inlay hints for a C# VSCode extension) it kept on failing and never made it work. Even with me guiding it as good as I can. And I tried for a good 4 hours. So yeah, there's still way to go for AI. Right now, it's not as good as the amount of money dumped in would make you believe, but I'm willing to believe that this can change.
- Care to elaborate?
- Is it just me or does the discourse about a product like the Fairphone often feel kind of "culture war"-y? So many times I read comments where people are very upset and offended how a Fairphone costs way too much compared to other smartphones or how it supposedly is completely unusable because one feature does not work the way they expect. It's just strange. If you don't like it, don't buy it, no need to engage. But so many people seem to feel obliged to present their strong dislike for the Fairphone as if it's sole existence attacks them personally.
- Genuine question, why should I use this to deploy models on the edge instead of executorch? https://github.com/pytorch/executorch
For context, I get to choose the tech stack for a greenfield project. I think that executor h, which belongs to the pytorch ecosystem, will have a way more predictable future than anything Google does, so I currently consider executorch more.
- Funny, I was just commenting something similar here, see https://www.hackerneue.com/item?id=44071614
And I say this while most certainly not being as knowledgeable as this openai insider. So it even I can see this, then it's kinda bad, isn't it?
- I was just going to answer https://www.hackerneue.com/item?id=44071595 who mentioned exactly the same tweet.
I'm nowhere as good at my craft as someone who works for openai, which the author of that tweet seems to be, but if even I can see this, then it's bad, isn't it?
Imo this is a really strange characterization of RISC. I've never seen this before. I think you try to paint a misleading picture in bad faith, please consider this: - https://riscv.org/blog/how-nvidia-shipped-one-billion-risc-v... - https://tenstorrent.com/en/ip/risc-v-cpu - https://blog.westerndigital.com/risc-v-swerv-core-open-sourc... - https://www.sifive.com - ... - https://riscv.org/about/ -> "RISC-V International Association in Switzerland"