421–430 of 754 posts
Earlier quoted context omitted.
I meant my comment not the rewrite
Ah, fair enough then, you mean want to clarify that a bit as it can be interpreted both ways. And the whiny baby part seems a bit uncalled for and distracting from the point you’re trying to make.
Earlier quoted context omitted.
Zig doesn't even have RAII...
which is a good thing. C++'s RAII is magic-sauce that does a lot for you when you can simply use `defer` in zig. A constructor is just a function call. A destructor is just a function call.
Earlier quoted context omitted.
Much less than what it’d costs for a team of rust engineers. This is both amazing and scary; has been for a while now.
It costs several times what it would cost a small team of engineers, even assuming you gave the engineers more time to do it. I'm guessing (wildly) this was around 0.5M USD in compute time. You do get the result quicker, though.
That seems like an especially wild guess. If you take e.g. Opus 4.7 prices, and make the assumption that you are consuming roughly $30 for every million tokens of output (this comes from just summing the $25 per million tokens of output and $5 per million tokens of input and assuming that caching basically makes all that work out), and assume an output rate of 80 tokens per second (which seems like a high estimate based on online searching), it would take you about 2411 days of non-stop Opus 4.7 usage to hit 500k in API spend.
The only way you could possibly run that amount of usage in 6 days is if you were running ~400 instances in parallel. From personal experience, that seems crazy high for this project.
I think you are off by at least an order of magnitude (potentially even 2 depending on how the person is managing agents, but I could see something like dozens of agents 24/7, so I'm way less confident in 2, but I think it's still more likely to be closer to 10-20k in API spend).
What does this mean for Zig? Few big popular projects use Zig, if they start to move away from it, what Zig's future will look like?
I think the issue is that Zig lost their biggest project, which was a posterboy project for real uses of Zig. Worse, the project felt like Zig wasn't meeting their needs, to the point they abandoned Zig and rewrote their entire project in a different language. Really bad signal for anyone thinking of using Zig for a big project. It is still in beta, but has there been any situation like this, where a upcoming program…
Bun, Ghostty, and TigerBeetle are 3 popular projects that I have heard about using zig.
Earlier quoted context omitted.
Running an experiment, the experiment being more successful than you thought, and then deciding to put more effort into a bigger experiment is not hypocrisy. It’s engineering. If you think some of the objective facts they’re putting out (like test coverage and performance) are lies, go and prove it instead of appealing to emotion.
Especially if given near unlimited tokens to burn through, because any level of success fuels the LLM hype machine, which brings ROI. > It’s engineering. Significantly, but not totally. The marketing value can't be ignored.
More handwaving about the LLM hype machine is incredibly boring and enough of it is spewed everywhere that whatever social good it was going to accomplish must have already happened by now. If you want to inject reality into the situation, talk about reality (like Anthropic is at least pretending to).
What does this mean for Zig? Few big popular projects use Zig, if they start to move away from it, what Zig's future will look like?
When I read about Bun, I get the sense that Jarron has different priorities, mainly moving quickly. Bun also implements a lot of userspace APIs, since the core engine is JavaScriptCore which is written in C++. I think Rust really shines in applications programming, so I guess it makes sense that Rust has lined up with Jarron's needs. I'd be interested to see what JavaScriptCore would look like in Zig versus Rust, I think Zig might have an edge in the core interpreter and JIT.
I love Bun & Zig and this feels a bit like my parent are getting a divorce. I thought it was a bit strange that Bun did not sponsor the Zig foundation while others much smaller companies have.
Completely unbased, but I don’t want to have to do anything with bun anymore. It’s just a gut feeling, but I don’t trust them and support them. They fork Zig to utilize LLM rewrites and build something the Zig team clearly disregarded (non-deterministic compiling) And now like a whiny baby they LLM rewrite to Rust. There is a very real chance that Zig design philosophy got them to the point where they are now by enfo…
Earlier quoted context omitted.
The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable
> The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable That code is also hyper-optimized for performance . I sincerely doubt you are going to match the performance easily with any random rewrite. Now, if you had a very clear idea of why the code was making assumptions from the 1990s that are no longer valid, then you mi…
Solving sets of differential equations is something that's parallelizable though
See for example how there's physics engines running on GPU. That's mechanics and not electric circuits, however it's differential equations all the same.