There's certainly assembly that maps directly to the machine language bytes, I assume you are talking about the version of assembly with the high level loop macros
Apr Fools Day really is the shittiest day to be online. For one thing, practical jokes/pranks are just gussied-up asshole behavior. For another thing, nerds generally SUCK at information-delivery pranks, which is what the Internet is full of on Apr 1.
Back in 2004 when free email services like hotmail were limited to 10-15mb, on April 1st the evening standard front page headline, which I saw in the office around 2pm, was something “Google lunched 1gb email”
I couldn’t believe they had fallen for an April fools so hard.
> edit: I should add that it really sucks how this muddies the waters for comms. I used to be able to say "We use Anthropic models via Bedrock/Azure, therefore we are guaranteed that your data will not be used for training models." That was simple comms. Now, it's not that simple.
This is massive and an insane move from Anthropic. They should have worked with AWS to have the retention done entirely in AWS infra and disabled the retention on their side.
Exactly. See my downthread comment. That is my proposal as well. I understand that Anthropic and Azure/AWS have different priorities, so even if Anthropic forward-deployed/embedded/rotated their own people into those teams to keep them honest, as long as user data didn't flow back... I would be fine with that.
For a model, yeah absolutely. You'll spend virtually 0 tokens on memory safety, which means your token budget gets allocated elsewhere. If you wrote a C codebase you'd need to allocate some portion of your budget towards memory safety.
Let's expand the actual quote we're responding to:
> the borrow checker woes can be offloaded to the model, you focus on all the other programming logic
Then the person you responded to asked if "you" really do "focus on all the other programming logic", given that "the model" deals with the borrow checker. In other words, they're asking about the work the actual human is doing at that point. You then replied talking about the model again and token budgets. In effect, you brushed the question under the rug and imply that _everything_ is offloaded to the model, no focus by the human required.
Yes, languages from decades ago continue to support OOP. I don't know what your point is. As I said, the industry has moved on from the OOP-craze and so the languages that hamstring you into everything being OOP are not as interesting to people these days.
Go and Rust also do OOP, even if it isn't the Java OOP model everyone only knows about.
In fact both languages conveniently map to COM object model, and Microsoft is putting that to good effect.
Than we have Swift and Kotlin, plenty of OOP on those Apple and Google frameworks.
Zig, Odin, remain to be seen how industry relevant they will be, and yet examples of structs with function pointers abound among their projects, C OOP style.
If I had to guess, some humans skim things quickly for structural red flags, a bunch of LLMs do reviews based on various humans prompting to look for mistakes/ bugs, and then "tests pass == the code is good to merge".
> Memory safety is just a tiny part of over all security.
No, it's a pretty massive part with disproportionate severity.
> If a LLM can transcode correctly, then it should also output 100% correct C code.
Translating code seems to largely rely on having a strong suite of existing tests, not on ability to code correctly.
It's unclear if LLMs are great at writing safe C code, it's much clearer that they can meet targets with external feedback properties like "test passes/fails".
> On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.
I think we are talking about ROI in terms of solving real world problems and making real impact, not the fact that a tool has been ported from language X to language Y.
Given the author already admitted that the implementation was slow anyway, you are no better off of using gitoxide instead and that has support for Windows where-as Grit does not.
> Currently both Gitoxide and libgit2's networking functionality is either partial, slow or non-existant. Both GitButler and Jujutsu rely on forking out to Git in order to push or pull data. A big reason for this is the incredibly complicated credential logic involved, but all of this is (theoretically) currently covered in Grit.
> One of the main things I would like to be able to use it for is to be able to bundle complex push/fetch functionality into GitButler and other standalone Git tools needing network functionality (such as Jujutsu).
> Having parts of Git as discrete, embeddable slices of library also enables things like building custom Git servers or client functionality in Rust.
> The full build of all Git functionality in Rust is currently around 27M, but since a large part of it is a library, it could clearly be easily split up into domains of functionality - subcrates that do specific things. Perhaps you could simply use the subset you need.
The article starts out with paragraphs about the history and motivation.
> it made me wonder about the feasibility of using that same approach to accomplish something I've been dreaming about for 15 years now,
> which means that it's difficult to use it in long running processes without fork/exec overhead for everything.
> What if we used the same basic idea that Anthropic used on their from-scratch C compiler? Start a brand new implementation, design it as a Rust library, then throw a swarm of agents at the problem
Yes, but that's actually a huge win. I can't know what a package needs to do at install time - the dev knows that. But I know what my tests and program need to do at runtime because it's my job to understand those things.
The dev has to be responsible for ensuring that their build scripts are safe, I need to be responsible for ensuring that my runtime is safe.
It'd be great to have more tools for untrusting libraries (iframes are awesome for this on the frontend) but this is still a massive win.
Security is the punch line for ffmpeg.
reply