[flagged]
Claude Code uses Bun written in Rust now
801–810 of 920 posts
Re: Claude Code uses Bun written in Rust now
#802Oh good, the vibe coded prompt injection vector that casually accesses things in my home directory without permission is running on a vibe coded prerelease runtime using lots unsafe rust. What could go wrong?
Re: Claude Code uses Bun written in Rust now
#803Earlier quoted context omitted.
> People tried to "just do that" (write their programs in a memory safe way) in C and other languages with manual memory management for decades, and we have countless vulnerabilities that prove this simply doesn't work. Who are these "people" you speak of? It's possible to write software in low level languages that don't have these problems. Not a "non-zero" it might be possible, it can be done thoughtfully, and the…
Yes, it's possible . It's also possible for experienced pilots to fly an airliner completely manually for the full duration of a transatlantic flight without crashing. Still, over the last decades, autopilots and other assistance systems with ever more sophisticated features have been developed, and I would argue that without this technology crashes would be much more frequent than they are today. Same goes for memor…
> Same goes for memory management: you can do it manually, and it might work out most of the time, but if the programming language is helping you with it, the likelihood of memory safety issues decreases drastically. And the problem with avoiding these issues only by "meeting certain standards of rigour" is that you might only find out that you have failed to meet them years later, when you learn that your software has a vulnerability.
Zig does help you. Array slices, explicit nullability of pointers, defer errdefer, explicit allocators, built-in leak detection, bounds checks, overflow detection, the list goes on. If you need to play around on that side of the fence, Zig gives you a lot to make sure you don't mess it up. If we were talking about C I'd give you your flowers, but we're not. The most common issues and vulnerabilities that crop in C from manually managing memory are strongly mitigated by a quarter of that list.
Re: Claude Code uses Bun written in Rust now
#804Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript” The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO. If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.
It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question. They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture. Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rig…
Massive business success? I don't know the financials since they're not published, but google says the acquisition cost low hundreds of millions. So they could throw away the code and rewrite it.
Re: Claude Code uses Bun written in Rust now
#805Earlier quoted context omitted.
Going to give a short reply to one point because I’m about to go to sleep (I try to make an effort to be honest as to why I’m not fully engaging with the entire comment) but re: strawman, I don’t think so. When Dario Amodei is saying SWEs will be replaced soon [0], I think it follows that then he believes Claude can write a native app as well as a native app dev. 0 - https://finance.yahoo.com/news/anthropic-ceo-predi…
CEOs love to promise the sky and the stars. Color me unimpressed. Now whether they can do it -- that's a separate, and a much more interesting, discussion.
Oh yeah, I mean I certainly think it’s a false premise. But it is a premise someone is giving.
Re: Claude Code uses Bun written in Rust now
#806Earlier quoted context omitted.
Zig is intended to be as robust as it can be as long as it doesn’t implicitly add code (no destructors that run code you didn’t explicitly call), or increase compiler complexity and compilation time. I don’t think it makes sense to say Zig is or isn’t intended to be robust in general. Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more gen…
A casual read of TigerBeetle's practices makes it clear they're doing some very unusual things, both in their memory allocation strategy and in their testing/verification. Despite TigerBeetle being one of the highest-profile remaining Zig projects, I actually don't think they're representative of the average Zig project at all.
It is quite representative of an embedded software project. TigerBeetle is not what we usually call embedded software, but it is built like it: static memory allocation, a self-contained executable, and a strong focus on determinism are typical in that field, especially for critical software.
And I think embedded software is a field where Zig will be at its best. The only thing it is missing is maturity. When project lifetimes are measured in decades and changing a single byte can cost millions, no one in his right mind will pick a language that is still in development. Things will become interesting when it reaches 1.0.
Re: Claude Code uses Bun written in Rust now
#807Earlier quoted context omitted.
It’s my understanding that bun was ported to unsafe rust, so even these gains would require additional effort on the team’s part, right?
Unsafe Rust doesn't automagically disable typesystem (& borrow checker, but lifetime are a sort of types). Once raw pointer is turned into a T, &T or &mut T, the borrow checker is on.
Yeah but if you have tried writing unsafe Rust, you notice that you are obligating yourself to write code that is much stricter than C.
E.g. in C you can write code and say "don't call it outside the situation that this function was written for" and then blame [0] future users of the API.
In Rust you need to actually make sure that your code works, i.e. your safe interface is not unsafe.
[0] The blame game is not a technical solution to a technical problem...
Re: Claude Code uses Bun written in Rust now
#808[dead]
Re: Claude Code uses Bun written in Rust now
#809Earlier quoted context omitted.
> True, but unsafe let's you conjure up any lifetime you want The only thing unsafe does is let you have an unbounded lifetime. As I said, it doesn't check those: fn get_str (s: *const String) -> &'a str { unsafe { &*s } } https://doc.rust-lang.org/nomicon/unbounded-lifetimes.html > if you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker Yo…
What's the point of using Rust in the first place when you disable the compiler feature that protects you the most?
Well, Rust has things like miri that can help you write your unsafe code and it's just a command line invocation away.
Obviously you should try to avoid writing unsafe Rust to begin with.
Re: Claude Code uses Bun written in Rust now
#810Earlier quoted context omitted.
> True, but unsafe let's you conjure up any lifetime you want The only thing unsafe does is let you have an unbounded lifetime. As I said, it doesn't check those: fn get_str (s: *const String) -> &'a str { unsafe { &*s } } https://doc.rust-lang.org/nomicon/unbounded-lifetimes.html > if you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker Yo…
> The only thing unsafe does is let you have an unbounded lifetime. No, you're wrong: You can create any lifetime. Proof: fn oof (x: &u32) -> &'desired u32 { let ptr = x as *const u32; unsafe { &*ptr } } This will take a reference and return it with any lifetime specified by the caller. > You don't disable anything. I said " effectively disable". For example: fn trust_me_bro (x: mut u32) -> &'a mut u32 { unsafe { &mu…
> Proof:
You just listed examples of unbounded lifetimes.
> I said "effectively disable". For example:
Not sure what you meant by this example since it doesn't compile. It seems the borrow checker caught your mischief. So much for effectively disabling stuff :P
You haven't effectively disabled anything; you just (tried to) wrote unsound code that washes one mutable ref as another. This stuff is allowed provided shared refs are never accessed at the same time (for example, panicking upon reading reference_b).
What you probably meant is https://play.rust-lang.org/?version=stable&mode=debug&editio...
But you know what? If you're dabbling in unsafe, you have this big button called Tools in the playground. Choose Miri, then run your code; it will display large Undefined behavior. It even highlights the `trust_me_bro` function.
Hell, run this with UBSAN, ASAN, and other C tools. They will probably catch any such behavior.