3 ms·

> The main problem, however, was code quality. > The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineerin

> The main problem, however, was code quality. > The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it. Perhaps the amount of bugs comes from using a C-like language that requires meticulous manual care to avoid writing runtime bugs. Even C++ would be a safer choice because of RAII. When you have to dedicate significant resources to avoid/fix runtime issues that are made impossible at compile time by other languages, the programmer isn't entirely at fault.

coffeeaddict1 3mo ago
C++ would also introduce a myriad other subtle safety problems that would require years of expertise to even notice.
- mungaihaha 3mo ago
  I'd like to see an example
skydhash 3mo ago
I’ve not seen any languages that does not require meticulous care to avoid runtime bugs. Type checking and lifetime ownership eliminate some, but not all of them.
- fooster 3mo ago
  So less meticulous care then?
  - skydhash 3mo ago
    Not really, as you always need to check back on your assertions, especially at the boundary points where information about types and ownership are more axiomatic than the result of logical inference.
    - fooster 3mo ago
      Sure, but there are less assertions to check. The surface area and boundaries are smaller and more limited.
- nicce 3mo ago
  > Type checking and lifetime ownership eliminate some, but not all of them. They actually remove certain classes completely. E.g. lifetime ownership in Rust removes all bugs related to the reason why it is in the code syntax (a.k.a. lifetime markers remove use-after-free completely in Rust.)
  - mungaihaha 3mo ago
    Almost like how RAII in C++ does it?
    - nicce 3mo ago
      RAII in C++ is optional and not enforced everywhere. It certainly helps if you use it. In Rust you can't turn it off.
      - mungaihaha 3mo ago
        unsafe?
0x000xca0xfe 3mo ago
Memory safety problems are still possible in the new Rust Bun: At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library.
- dralley 3mo ago
  Possible, yes. But it's not like it's terribly difficult to verify correct usage of "unsafe" that amounts to a basic function call to a C library. Trivial uses of unsafe are pretty innocuous.
- mtndew4brkfst 3mo ago
  Yes but through iterative ratcheting, some portion of that unsafe can likely be migrated to idiomatic code without unsafe. And the other 96% of the code now has more mechanical guarantees than it did before. Static linting in Rust via clippy also makes it pretty straightforward to begin enforcing things like "unsafe blocks need to have safety doc comments" as a CI warning or failure, and there are community tools that focus on this topic too. I can't stand the practice of "LLM porting" personally but if you're going to do a mechanical rewrite from something else into Rust, this (permit unsafe and unidiomatic but 1:1 translation at first) is a fairly reasonable strategy imo.
- atombender 3mo ago
  People bring this up a lot. What I see here is that thousands of potentially (not actually, just potentially) safety risks have been neatly tagged in the code. If you took a program written in Zig, Go, C++, or C, you would have no idea which parts of the code were potentially unsafe. In those languages, the entire program is one big unsafe{} block. Rust isolates unsafe code. Having them explicitly tagged means they're isolated and can be eradicated over time, if need be. Though in many cases, unsafe blocks are quite safe.
- ptx 3mo ago
  > 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library Don't those blocks need some additional lines for error checking to prevent the unsafety from spreading to the safe code?
geraneum 3mo ago
You have to put similar amount of resources when writing in Rust as well. With the difference that it’s more front loaded. Personally I’m a fan of Rust’s approach but the price for having bug free code has to be paid, regardless, one way or the other.

coffeeaddict1 3mo ago

C++ would also introduce a myriad other subtle safety problems that would require years of expertise to even notice.

mungaihaha 3mo ago
I'd like to see an example

skydhash 3mo ago

I’ve not seen any languages that does not require meticulous care to avoid runtime bugs. Type checking and lifetime ownership eliminate some, but not all of them.

fooster 3mo ago
So less meticulous care then?
- skydhash 3mo ago
  Not really, as you always need to check back on your assertions, especially at the boundary points where information about types and ownership are more axiomatic than the result of logical inference.
  - fooster 3mo ago
    Sure, but there are less assertions to check. The surface area and boundaries are smaller and more limited.
nicce 3mo ago
> Type checking and lifetime ownership eliminate some, but not all of them. They actually remove certain classes completely. E.g. lifetime ownership in Rust removes all bugs related to the reason why it is in the code syntax (a.k.a. lifetime markers remove use-after-free completely in Rust.)
- mungaihaha 3mo ago
  Almost like how RAII in C++ does it?
  - nicce 3mo ago
    RAII in C++ is optional and not enforced everywhere. It certainly helps if you use it. In Rust you can't turn it off.
    - mungaihaha 3mo ago
      unsafe?

0x000xca0xfe 3mo ago

Memory safety problems are still possible in the new Rust Bun: At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library.

dralley 3mo ago
Possible, yes. But it's not like it's terribly difficult to verify correct usage of "unsafe" that amounts to a basic function call to a C library. Trivial uses of unsafe are pretty innocuous.
mtndew4brkfst 3mo ago
Yes but through iterative ratcheting, some portion of that unsafe can likely be migrated to idiomatic code without unsafe. And the other 96% of the code now has more mechanical guarantees than it did before. Static linting in Rust via clippy also makes it pretty straightforward to begin enforcing things like "unsafe blocks need to have safety doc comments" as a CI warning or failure, and there are community tools that focus on this topic too. I can't stand the practice of "LLM porting" personally but if you're going to do a mechanical rewrite from something else into Rust, this (permit unsafe and unidiomatic but 1:1 translation at first) is a fairly reasonable strategy imo.
atombender 3mo ago
People bring this up a lot. What I see here is that thousands of potentially (not actually, just potentially) safety risks have been neatly tagged in the code. If you took a program written in Zig, Go, C++, or C, you would have no idea which parts of the code were potentially unsafe. In those languages, the entire program is one big unsafe{} block. Rust isolates unsafe code. Having them explicitly tagged means they're isolated and can be eradicated over time, if need be. Though in many cases, unsafe blocks are quite safe.
ptx 3mo ago
> 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library Don't those blocks need some additional lines for error checking to prevent the unsafety from spreading to the safe code?

geraneum 3mo ago

You have to put similar amount of resources when writing in Rust as well. With the difference that it’s more front loaded. Personally I’m a fan of Rust’s approach but the price for having bug free code has to be paid, regardless, one way or the other.