Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

github.com

Post reply on HN
Print view View original

271–280 of 366 posts

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#271

Post by theamk »

gpm wrote: post #77

This issue is misleading. The issue isn't the existence of undefined behavior that miri would catch. The issue is exposing an API that allows undefined behavior from safe code - which miri only catches if you go write the test that proves it. This isn't an all together unreasonable thing to happen during an initial port of code from an unsafe language. You can, and the bun team seems to be, go around later and make s…

Once project reaches 1.0 for the first time, a lot of people expect that "main" branch is now working all the time. That's what the whole "CI/CD" is about after all - every commit should work.

If you are making a full rewrite and have non-working, in-progress code, you use a branch. This way you can still have the working "main", in case there is a security fix needed or something.

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#272

Post by jadar »

skippyboxedhero wrote: post #227
jadar wrote: post #140

> Please consider not vibe coding rust as AIs are not good at writing Rust and also hire a real rust dev Isn't the whole point of AI companies using Rust that it's explicit, safe, and AIs are fairly good at writing it?

AI is not good at writing Rust. The ways in which it is bad vary from writing code that just looks off to actually not working. I do not use unsafe frequently so cannot comment on this particular scenario but I have seen similar stuff often, most Rust code that I read from AIs has at least one or two issues. In particular, if you have a situation that requires any kind of conceptual understanding then AI will likely…

Couldn't you say that about any code written by AI in any programming language, though? You might as well say "AI is bad at writing code".

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#273

Post by jadar »

minimaxir wrote: post #165
jadar wrote: post #140

> Please consider not vibe coding rust as AIs are not good at writing Rust and also hire a real rust dev Isn't the whole point of AI companies using Rust that it's explicit, safe, and AIs are fairly good at writing it?

I suspect "Rust is fast/low memory utilization" is the more common value proposition, with memory safety as the bonus that can push it over other fast languages. Related: If AI writes your code, why use Python? (which notes why Rust has taken off for LLMs) https://news.ycombinator.com/item?id=48100433

I would imagine that the strong type system would also help steer AIs to ensure that code is written correctly. The compiler supplies backpressure to the agent that steers it toward a more correct program.

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#274

Post by arjie »

whimsicalism wrote: post #268
arjie wrote: post #265

Earlier quoted context omitted.

I just wrote a Chrome extension to do it: https://overmod.org/ But tbh this is trivial to write these days since the boilerplate can be written by the machines and you can just write the core functionality to make it work. I only have it public because I'm hoping others will also block users who misinform as a habit and I can subscribe to their lists and crib off their work without having to do it myself. If you want…

i was going to follow up with the same thought - it would be nice to have shareable blocklists à la bluesky

Yeah, I suppose a nice fully featured protocol would use something decentralized, but that extension currently has them on my site. e.g. Another user made this one and I subscribe to it too: https://overmod.org/lists/view?pk=0STtY8mc3j6Pyaaf3YeKGHkcBK...

I separate mine by a bunch of categories which might be a bit complicated, but I was hoping perhaps people might not care about some of the categories https://wiki.roshangeorge.dev/w/Overmod#My_Stuff

e.g. I don't like endless repetitious "but corporations" stuff and I also don't like "but they sell your data" repetitively but maybe others want to block category A but not category B.

I think that wasn't a sound idea, though. Either people trust you to block for them as well or they don't.

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#275

Post by nextaccountic »

mohsen1 wrote: post #67

I was a little shocked that they could get it fully working in a week to be honest. My side project is a very similar ambition ( https://tsz.dev ) but I am in no way claiming success. i keep adding more and more tests to ensure things works. Even after all of TypeScript's own tests pass I am finding bugs which I was totally expecting. The bar for matching tsc's behavior is really _really_ high. see: https://github.co…

https://tsz.dev/sound-mode/

This is awesome. Typescript really needs more of this. I hope this gets more publicized and perhaps get adopted by Microsoft.

I am not sure you should call it sound mode though.

> It is not a mathematical proof of soundness, and it does not make third-party .d.ts files truthful.

Here there are two completely unrelated things

First, soundness is a mathematical thing (sorry). If something is sound, it's really really sound. Soundness is the thing that says we don't need to manually check the details - we can trust the compiler to do the right thing. It will do the wrong thing if there's a bug, but the implementation can be fixed. Soundness means there's is no bug in the spec, no bug in the type system that would make things go wrong even in theory.

Second, and here's the important thing.. it's entirely okay and expected that real world languages need to have unchecked features where we trust the humans to do the right thing, rather than trusting the compiler to verify. That's like Haskell's unsafeCoerce or Java's sun.misc.unsafe. The problem really is when the type system breaks even when we don't do any of those

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#276

Post by mohsen1 »

nextaccountic wrote: post #275
mohsen1 wrote: post #67

I was a little shocked that they could get it fully working in a week to be honest. My side project is a very similar ambition ( https://tsz.dev ) but I am in no way claiming success. i keep adding more and more tests to ensure things works. Even after all of TypeScript's own tests pass I am finding bugs which I was totally expecting. The bar for matching tsc's behavior is really _really_ high. see: https://github.co…

https://tsz.dev/sound-mode/ This is awesome. Typescript really needs more of this. I hope this gets more publicized and perhaps get adopted by Microsoft. I am not sure you should call it sound mode though. > It is not a mathematical proof of soundness, and it does not make third-party .d.ts files truthful. Here there are two completely unrelated things First, soundness is a mathematical thing (sorry). If something is…

Thank you for the feedback. I think I should rename the "Sound Mode" to something more honest. "Strict" is already taken so I should think of a better name. Making tsz compatible with tsc and making it sound is mathematically impossible. The history of this stuff (https://hegel.js.org) is telling. If you really make a sound JS checker, nobody will really use it unless you build an entire ecosystem as big as npm with it. TypeScript's decision to embrace existing npm ecosystem and layering .d.ts on top was a very practical decision that made it so successful.

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#277

Post by Animats »

eschew wrote: post #266
Animats wrote: post #145

Earlier quoted context omitted.

What comes out of c2rust is not intended for human consumption. It's more verbose than the original and harder to work on, but no safer. You lose the C idioms that people understand, while not gaining Rust idioms. It's like working on compiler-generated assembly code by hand. 2022 discussion on HN.[1] There's a DARPA funded effort called TRACTOR, Translate All C To Rust, which has funded some efforts to develop a usa…

Here is a public report from the TRACTOR evaluation team: https://github.com/DARPA-TRACTOR-Program/Reports/blob/main/F... There are also some papers being published that were funded by TRACTOR, such as https://homes.cs.washington.edu/~mernst/pubs/c-rust-macros-p...

Evaluations of six translators. That's real progress.

Here are the test cases for evaluation #1.[1] There's good coverage of the C language, but the individual tests are mostly simple exercises of one C feature. The next round of test cases will probably be closer to useful programs.

[1] https://github.com/DARPA-TRACTOR-Program/PUBLIC-Test-Corpus

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#278

Post by kibibu »

gorjusborg wrote: post #229

Here's the thing: I was first interested in Bun because it was written in Zig. I was interested in Zig because I respected Andrew Kelley's decision-making, and his taste matched my own. I got really excited about Bun for many reasons after that, but they essentially came down to a similar root: the decisions were ones that I respected and would probably have made myself if I had thought of them. I was a little concer…

What attracted you to Bun over Deno?

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#279

Post by teiferer »

gpm wrote: post #247
teiferer wrote: post #244

Can somebody explain what the issue is? In particular, if Rust is safe, and this is safe code, then how can there possibly be use-after-free? I thought it's the entire point of the "safe code" thing that it's ..safe by construction.

> and this is safe code, The code they are complaining about is not safe code, it is unsafe code that exposes a supposedly but not actually safe interface. They demonstrate this by using the interface to get undefined behavior. You can see this rather directly by how miri points to the exact line of unsafe code that results in undefined behavior (which isn't something miri can always do, but it can in this instance).

But how can an interface be considered safe if it actually isn't? I thought the Rust compiler guarantees safety of everything marked a such?

Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

#280

Post by gpm »

teiferer wrote: post #279
gpm wrote: post #247

Earlier quoted context omitted.

> and this is safe code, The code they are complaining about is not safe code, it is unsafe code that exposes a supposedly but not actually safe interface. They demonstrate this by using the interface to get undefined behavior. You can see this rather directly by how miri points to the exact line of unsafe code that results in undefined behavior (which isn't something miri can always do, but it can in this instance).

But how can an interface be considered safe if it actually isn't? I thought the Rust compiler guarantees safety of everything marked a such?

It doesn't. The rust compiler exposes a rich type system by which the programmer can make safe abstractions around unsafe code that can't be misused, but it doesn't (and fairly fundamentally can't, thanks to Rice's theorem) verify that people who write unsafe code and purport to have made safe abstractions actually did so.
Post reply on HN