Point is, frontier models don't necessarily are better than a swarm of non-frontier ones for these scoped problems. IMO frotnier models excel at underspec'd or more complex problems where ideation and exploration are key (and that's where they become crazy expensive).
Hey, for all of us builders out there, this is some quality work you're putting out there. How do you handle to talk about it, distribute it, just basically making it known to people, and still have time to focus on delivering actually useful, extensible quality work?
For more general Go practitioners like me, is there any harness/tooling I can bring into my projects to identify these bottlenecks (aside from profiling if any). More specifically, tooling that identifies workflows that actually have greater changes to be fine with 'unsafe'.
As a developer without deep know-how in low-level memory mgmt., what are the most promising (or actually working) approaches to safer memory mgmt. other than Rust's borrow checker? Is Rust's credited safe approach mainly due to the borrow checker approach or rather a mix with other language features?
Cool stuff! I see you're targeting two verticals here (runtime on top of ONNX + TS library), I'm curious did you consider simply creating a AI SDK Provider (https://ai-sdk.dev/providers/community-providers/custom-prov...) instead of crafting a separate library?
Besides it, how are you dealing with the harness the model can use on web? I'm currently building https://github.com/bolojs/bolo to extend the base harness agents can use on web and I'm interested in hearing from your experience on crafting tools for bitgpu
> The only browser supporting Safari, Chrome, and Firefox extensions
Honestly it's nuts you've cracked a way to support all three of Safari, Chrome and Firefox extensions. In my experience while developing browser extensions, providing support for all three is somewhat of a headache.
Care to share more insights on how you did it, or even launching/supporting a browser extension framework to ship browser extensions?
Wow, I see you managed to fit in so many models (krea, wan, hunyan, etc.). Did you get to build a common harness to run all of them? Which ones stay under your VRAM budget more consistently?
Thanks for the detailed walk-through @manucorporat .
On designing for zero breaking changes, I see that is also a core value at Go. However, how did you actually apply it to software design and architecture? Got any resources to share here? Did you had to put more effort on other projects not running on Go to keep it also free from breaking changes?
I'm mainly building tooling in other runtimes like Rust and TS, and I'm interested to hear your take on it.