861–870 of 920 posts
Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust. Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people miss…
Earlier quoted context omitted.
> 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 share…
> You just listed examples of unbounded lifetimes. You're just splitting hairs and trying to weasel around the fact that yes, you really can create any lifetime you want using unsafe . > Not sure what you meant by this example since it doesn't compile. That's because the crappy HN formatting ate some of the characters. Here's the original version: https://play.rust-lang.org/?version=stable&mode=debug&editio... > What…
No. I said borrow checker allows unbound lifetime. I didn't disagree with you. I noted you didn't read the argument.
> If you know what I meant, then what's up with your snarky comment about "So much for effectively disabling stuff"?
Because your original code looked like trying to cast mut u32 to pointer.
> you did effectively disable the borrow checker in safe parts
So this code (https://play.rust-lang.org/?version=stable&mode=debug&editio...) runs now?
Effectively means achieving the goal in satisfying manner.
Writing unsound code is less of effectively disabling borrow checker and more of a hack.
Think about it, if using Java unsafe I gain access to underlying HashMap array and do weird stuff to the HashMap invariants am I effectively turning HashMap into Array or am I doing a hack job?
Edit: By that logic since there is so much unsafe in the code base isn't borrow checker effectively already disabled? You can argue semantics but no, borrow checker isn't de facto or de jure invalidated by unsafe blocks.
It's invalidated by unsound unsafe and that's on code writer to fix.
Earlier quoted context omitted.
You don't seem to understand what I'm talking about. bad axiom -> worthless theorem. bad unsafe section -> verified safe section is actually not safe.
I’ve understood the distinction. I just don’t like you equating “actually not safe” with “worthless”.
The proof that there are no (for rust's definition of "no") memory bugs becomes worthless, not the entire software itself.
Earlier quoted context omitted.
> by making it cheap and fast to build whatever you like automatically. Cheaper, but not free (if you don't buy into the marketing promises too much). The bigger the project, the bigger the cost, even with a discount. At the same time, the early versions weren't very good and you can be sure that any rewrite will also need to be similarly iterated upon until it is also good enough and polished. If you do that and don…
Can't have been that cheap if they thought buying Bun for an undisclosed amount of money was cheaper.
Earlier quoted context omitted.
Yeah, one needs to understand that "unsafe" does not mark which parts of the code are actually unsafe, it simply marks parts where the compiler ignores parts of its rule set. But the implications can crop up anywhere, there is no guarantee that a resulting use-after-free or similar can only happen inside the unsafe blocks. In short, if you use an unsafe block, then potentially any part of your code is unsafe.
Right, so if I understand correctly, to make the code fully safe, it can be impossible? Because you have underlying dependencies which are unsafe. The best you can do is make the handling of the unsafe as safe and as restricted as possible. But I can imagine some of these are way more difficult than others, and in programming the last 10% can be the last 90% of the work. Alas in terms of perceptions, the argument wor…
Earlier quoted context omitted.
They can ship with whatever they want as long as it works.
Given the permissions Claude Code gets on many systems they should be more professional. They are basically testing the rust port on user machines. Who come that since the rise of AI all principles of software development are thrown over board?
Earlier quoted context omitted.
Then why do you care? If target users (developers) face issues with bun, they will stop using it. Go back to Node or switch to Deno. Bun has bugs? yes. Do they affect vast majority of users? Not really. Been using bun for about 3 years; never had an issue with it.
Are you interested in the discussion that was taking place before you popped in or are you just here to get outraged that something you clearly identify strongly with is getting criticism for making poor choices? "Because the discussion was interesting" is why I care.
The worst is "hey they are running proprietary fork and not open source anymore" when the code is available in plain sight. Canary build is available with one command. The stupid article made a huge stink about it without this key fact. Now they added the update but damage is done.
Earlier quoted context omitted.
I’ve understood the distinction. I just don’t like you equating “actually not safe” with “worthless”.
So you haven't understood the distinction or you're letting your feelings for software get the best of you. The proof that there are no (for rust's definition of "no") memory bugs becomes worthless, not the entire software itself.
Maybe? I'm not sure.
> The proof that there are no (for rust's definition of "no") memory bugs becomes worthless
I still don't think so, the proof that there are no memory bugs is definitely not worthless, since while the whole proof itself is binary (it is either fully correct or not), its effects act more like coverage, and the more of it that happens to be partially correct, the better.
I think cve-rs is the perfect example of this. Its very existence proves that the borrow checker is already unsound, and with that, the very foundations of Rust's safety guarantees are currently flawed.
TypeScript is another good example, its type system has been repeatedly proven to be unsound, so it's also flawed.
But so what if it's flawed? Many smaller properties of these proofs still happen to hold, and they might prevent 90%+ of CVEs even as flawed as they are.
Earlier quoted context omitted.
Except the transition was never necessary. Yet another Anthropic marketing effort so they could claim a shallow victory [0]. [0] https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
Creator of language has opinions on big project moving off language. News at 11.
Earlier quoted context omitted.
Are you interested in the discussion that was taking place before you popped in or are you just here to get outraged that something you clearly identify strongly with is getting criticism for making poor choices? "Because the discussion was interesting" is why I care.
Discussion was not interesting. It was built on speculation as facts and lies as facts. The worst is "hey they are running proprietary fork and not open source anymore" when the code is available in plain sight. Canary build is available with one command. The stupid article made a huge stink about it without this key fact. Now they added the update but damage is done.
If you would like to join us in this thread now that this misunderstanding has been corrected, please, share your thoughts on the Bun community, what the "Bun community" even is, and how it has been impacted by a sudden, unannounced rewrite.