The main thing is getting feedback. I've been doing some intense agent iteration on Lua projects, and so long as the error output is clear and it's easy for the harness to restart/inspect/stream logs it seems to do very well with Lua
In fact, I'd say it's more "fun" watching an agent work on something in Lua as the iteration loop is tighter: more restarts, more feedback, instant running. When I deal with typed languages (in my case, Swift) the feedback loop is dragged-out by the compile time which makes the whole process feel slower
If the agent is at least reasonably good at your language, the errors that are getting caught at compile time in a language with reasonably expressive types like Swift should be actually catching and eliminating bugs without having the run anything. It seems like the ceiling of how long an iteration takes would be lower, but the floor would be a lot higher, and then you're making a bet that the number of iterations needed won't be so high that it takes more time overall to get things working, which doesn't strike me as obviously true (and that's not getting into how fast the final product will be when the agent is finished, although both Lua and Swift seem like they're most heavily used in domains where you don't really have an alternative choice, so it's not easy to really compare these anyhow)
> In fact, I'd say it's more "fun" watching an agent work on something in Lua as the iteration loop is tighter: more restarts, more feedback, instant running. When I deal with typed languages (in my case, Swift) the feedback loop is dragged-out by the compile time which makes the whole process feel slower
Ideally you'd want both. In this case though, if you're paying per token you'd prefer the typed language, since compiler invocations are presumably less expensive. So the interactive compilation strategy where it has to continually consume compiler output and run inference on it is going to be more expensive than letting the compiler do what it's good at. (I wonder at what point that math would invert and what would happen if it did.)
That's why something like Teal is perfect for AI, to answer the original question of "why this when there's AI now?" You'd want to add types to Lua to check what you can beforehand precisely because it helps give you the best of both worlds.
Hutter prize does have speed restrictions. If it did not, LLMs would win even with counting the size of the model (which is the most reasonable choice imo) as per the main benchmark: https://www.mattmahoney.net/dc/text.html.
Official Deepseek v4.1 Flash API costs are more than GPT 5.6 Luna. Deepseek v4 Pro performed worse than Luna, so I wonder if 4.1 Flash will justify the cost.
Hint: It's not 15%. And there are many reasons, such as not having to keep up-to-date billing details in 70 providers, and not wasting money because most providers want you to prepay a balance that gets stuck in there if you switch to another provider.
It also has way better uptime than the underlying platforms, even for proprietary models like Claude. When Claude APIs are having issues, OpenRouter Claude still keeps working because they can route to AWS Bedrock instead of Anthropic etc. This effect is even bigger with open-weight models because they typically have 5-10 providers.
They are imo clearly gearing up to lock down passkeys in practice one day so that you will only be able to use those tied to a Google or Apple account (or some new player). They're already threatening in these issues to blacklist open implementations that don't submit to their requirements, and then requiring an attested client would then become the "best practice" adopted blindly and widely. I think the only hope is for the open clients to fully submit, hoping to avoid full attestation, while not making it too hard to patch out the anti-features. Of course, anyone who can't compile is screwed though.
...and it characteristic the level of patronising arrogance in the issue thread
"This is normal. It is not recommended to copy passwords to the clipboard in any case, this mitigates this behavior and complies with new Web Authentication standards."
This does not even invite a discussion. Maybe some people run tight, safe systems and know what they are doing? Maybe some people never rely on a single password being the only thing between them an an account compromise? Nope. Some patronising guy knows it all, and will override what people want to do on their machines.
The issue is language ecosystems that don't use client side connection pooling because they're single threaded (node, Python). So scaling up the number of web server threads means scaling the number of Postgres processes, which are expensive.
Yes but they can’t be shared. If you size your pool to hold 10 connections (because asyncio can handle that and more), then deploy with uvicorn —-workers 4 (which should match the number of cores on your app server), and then deploy to 3 app servers (for redundancy) then you’ve now got 120 open connections to Postgres. Run anything more than a trivial query and you’re easily at gigabytes of ram.
120 connections is likely fine. If it's not, you could do only 5 connections per worker. This is more of a problem if you have uneven load on the workers though.
I’m not claiming it’s not fine, but it is a surprising consideration for a relatively small deployment. You have to start planning around Postgres’ architecture for anything larger, hence the solution in PgBouncer.
How many running instances do you need though? e.g. Scala web frameworks should be able to do thousands of RPS on a single core without the application developer really trying to optimize anything, and I always hear that even Ruby, Python, etc. are also fast enough to be IO bound so you should just need 2 copies for redundancy, right? Then give each like 8-16 connections.
That's fine but doesn't address the issue that PgBouncer does. Your application connection pool can multiplex all the connections needed in one application. PgBouncer can multiplex the connections across all applications (whether different apps or many instances of the same app).
reply