Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm surprised that performance wasn't on the list. The main reason I started Brokk on the JVM was for access to https://github.com/joernio/joern, but high performance code that can easily go multicore is a very nice secondary reason.


On the list:

> Optimized Performance — no runtime garbage collection, resulting in lower memory consumption

Introducing the list (efficiency resonates with me as a more specific form of performance):

> Our goal is to make the software pieces as efficient as possible and there were a few areas we wanted to improve:


gc is negligible impact on llm agents

the others ("zero dependencies") are not actually related to efficiency


It's not totally unjustified to hone in on GC as over focusing. But it feels strongly overfocusing to me.

Efficiency is the top level goal, and that equates directly to performance in most computing tasks: more efficiency means being able to let other work happen. There's times where single threaded outright speed is better, but usually in computing we try as hard as possible to get parallelism or concurrency in our approaches such that efficiency can directly translate to overall performance.

Overall performance as a bullet seems clear enough. Yes it's occluded by a mention of GC, but I don't think the team is stupid enough to think GC is the only performance factor win they might get here, even if they don't list other factors.

Even a pretty modest bit of generosity makes me think they're doing what was asked for here. Performance very explicitly is present, and to me, I think quite clearly a clear objective.


gc is especially not relevant in async flows. i don't know what they are optimising for..




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: