| |
| ▲ | galangalalgol 3 days ago | parent | next [-] | | The borrow checker really isn't that bad. It isn't like they were porting from something with GC. They were already having to think about these things anyway. Even then opus seems to have no difficulty going between c# and rust while respecting the idioms of both. No unsafe needed. Zig should be even easier except the lack of a training corpus for whatever frankenversion of zig that bun was using. | |
| ▲ | tialaramex 3 days ago | parent | prev | next [-] | | All that unsafe does in these cases is enable the "unsafe super-powers" which the compiler can't check, thus shifting the responsibility onto the author. But for example if you've got some code which doesn't borrow check, and you just sprinkle unsafe keywords on it, now you've got code which still doesn't borrow check and diagnostics telling that this unsafe keyword was futile and you should remove that. I haven't reviewed this code, but the percentages described don't sound like they'd need a huge architectural overhaul to use much less unsafe, it might take more actual human effort than they want though. | | | |
| ▲ | masklinn 3 days ago | parent | prev | next [-] | | Even if you “rely on countless unsafe blocks”, unsafe is additive, it gives access to additional APIs which are not checked. It does not disable affine types, the borrow checker, or send/sync traits. Unless the entire codebase is unsafe (e.g. fresh out of c2rust) it’s very hard to not have more guarantees. And because unsafe is generally highly local or localizable reasoning (conventionally backed by safety justifications) it really is quite reasonable to go plugging at it, or task an AI within that. | | |
| ▲ | cyber1 3 days ago | parent [-] | | For 99.99% of cases, you're reading and writing this under an operating system whose kernel is written in a language without send/sync, and inside a browser that also largely written in languages without send/sync, because those systems are fundamentally well designed. So instead of fixing the bugs and rethinking the architecture, the author of Bun decided to transpile almost the entire codebase from Zig to Rust without a deep architectural review. Okay... | | |
| ▲ | adwn 3 days ago | parent [-] | | Those systems you're alluding to received ungodly amounts of work and resources, vastly more than most projects can ever hope for, and yet they're still full of holes and security exploits. You're unwittingly making a great argument against using C, C++ – or Zig. | | |
| ▲ | iigijshaba 3 days ago | parent | next [-] | | Those systems are primarily written in C or C++-but-in-C-style, right? Without exploiting RAII among other features, as Jarred mentioned that he liked in Rust. While Rust took RAII from C++. | |
| ▲ | cyber1 3 days ago | parent | prev [-] | | What I mentioned is only a tiny part of the entire software, which has been successfully written in C, C++, and now in Zig as well, and is used daily by people around the world. |
|
|
| |
| ▲ | Ygg2 3 days ago | parent | prev [-] | | If you are writing in C-like codebase and aren't tracking lifetimes and ownership at least as well as a borrow checker you're opening yourself to CVEs. | | |
| ▲ | cyber1 3 days ago | parent [-] | | The concept of lifetimes was invented long before Rust borrow checker was even "scratched on paper." Of course, people who understand what they are they doing have known about these concepts for decades and have built their architectures around them. However, Rust borrow checker is much stricter than that. You have to build your architecture around the fact that you can't have more than one mutable reference at a time, and your data structures have to be represented as directed, acyclic graphs, etc. If you have to break all these rules by using a lot of unsafe because it's too difficult to represent your system within Rust safe subset using only value semantics and borrow-checked references, etc, then why use Rust instead of C++, C, or Zig? | | |
| ▲ | Ygg2 3 days ago | parent [-] | | Where did I say Rust's borrow checker predates lifetimes? I'm saying you have to be as meticulous as a borrow checker. Not as strict, of course, but you have to analyze each pointer, how and when it's used, and then cross-reference with the documented lifetime. Just like thread safety existed before Rust made it explicit. Now you don't need to investigate if data is thread safe if it's `Send + Sync`. This is a job humans suck at and compilers excel at. With some caveats. There will be edge cases that will need to be manually proven. |
|
|
|
