731–740 of 754 posts
Earlier quoted context omitted.
why do you think no one understands the code after the LLM rewrites it?
Becase no one has written it. You can't ask the guy who has written it, not because this guy has left, but because he does not exist. Also, it often reads weirdly.
Earlier quoted context omitted.
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.
> I'm guessing (wildly) this was around 0.5M USD in compute time. 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…
~7x overcompute * ~7x real cost to Anthropic * your 10-20k estimate for consumer use is my thought for actual total cost. If the honeymoon period runs out and they're still in business, this is what everyone will pay.
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…
Even if you avoid most of the numerical code initially, the interface in the original spice core is a mess of string handling and building a custom shell experience. There are tricks like setting the upper bit of every byte to 1 when inside quotes so that the custom shell history matching skips over things in quotes. Very elegant for the time, but now that means if you want nodes with non ascii names you're either keeping a mapping outside or using utf-7.
Another great example is the expression parsing. There was a long standing bug where the expression parser leaked ~160 bytes for every step of an output expression for every timestep. So for example, if you had "($2 * 4) + 1" as an expression and ran a simulation for 10,000 timesteps you'd leak 8M bytes.
Earlier quoted context omitted.
Nah. These agents are getting easier and easier to run local. Have you tried Qwen 3.6 27b? It’s insane what it can do compared to its size. Like 100% vibe small projects if you manage context properly. These models are a race to the bottom just like compute.
I don’t think it matters. Local matters becoming better has not stopped demand for SOTA models.
Earlier quoted context omitted.
I don’t understand: just use an agent to find all memory leaks and segfaults. I don’t get the argument if you are gonna vibe code anyway. With unlimited tokens make it a lint rule or auto formatter.
LLMs are a force multiplier, not magic. They benefit from good tooling.
Earlier quoted context omitted.
>It's not like Jarred has been begging the Zig devs to implement language changes to make Bun development easier. Zig was always upfront that you will have to manage memory manually, and that allows for operator error. Huh? The patch that Bun submitted was for Zig was about compilation times, and making Zig's type resolution faster. I am sure the Bun developer who is submitting patches to Zig is well aware that manua…
>Why would it make sense to use a language that is not helping you manage memory and is slow to compile, especially if you submit a patch to the language to address the issue and get rebuffed? You're right, other things constant, this would not make sense. But this is a strawman. Zig has fast compilation on average compared to systems languages with more automatic memory management, like Rust. In addition, Bun's fork…
Earlier quoted context omitted.
Downstream doesn't imply determinism.
The original claim is one of determinism. Your use of the term "downstream" is hiding the distinction; it can be read in either way, so it bridges the gap between the position you want to defend ("using Zig causes a higher probability of memory bugs") and the position you're forced to defend ("using Zig results in extremely many memory bugs"). In short, I'm accusing you of doing a motte-and-bailey.
I am less motte-and-bailey'ing, and you are more not subscribing to the principal of charity, choosing to interpret the original comment as its weakest possible version rather than the strongest.
Earlier quoted context omitted.
People *did* write down these logs, manually, and submit them.
And without software, what then, make a bunch of books and mail it to all these people? On this site of all sites, it's blowing my mind that this kind of thing isn't obvious to everyone. I guess maybe it isn't if you were born before the internet, but man, I'm really surprised by some of these comments.
Earlier quoted context omitted.
> If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. Yeah, I've heard of people being surprised that when they make massive collections of Box'ed entries, then get surprised that it takes a long time to Drop the whole thing. But this would be the same in C or Zig too. Malloc and free are really complex functions. Reducing heap allocations is an essent…
no, in zig it's never unexpected, because if you're freeing memory the freesite is known, it's a function call.
I understand zig's philosophy here. But I prefer rust's default behaviour.
Earlier quoted context omitted.
no, in zig it's never unexpected, because if you're freeing memory the freesite is known, it's a function call.
Right; because in zig the default behaviour is to leak memory. Rust adds an invisible free() call. Leaking is something you have to do explicitly. I understand zig's philosophy here. But I prefer rust's default behaviour.