30 ms·

No. It is not an invisible safeguard - it yaps and significantly increases compile time and (a matter of great debate) development effort. It is a helmet, just

No. It is not an invisible safeguard - it yaps and significantly increases compile time and (a matter of great debate) development effort. It is a helmet, just accept it. Helmets are useful.

rowanG077 1y ago
It is a helmet. But at least it's a helmet in situations where you get into brain cracking accidents multiple times a day. In the end the helmet allows you to get back up and continue your journey compared to when you had no helmet.
- mattwilsonn888 1y ago
  We're talking about Zig not C. Same argument will apply to Odin. These modern approaches are not languages that result in constant memory-safety issues like you imply.
  - pjmlp 1y ago
    Modern as in 1978 and Modula-2 was just made available. Or better yet, modern as 1961 Burroughs released ESPOL/NEWP and C was a decade away to be invented.
steveklabnik 1y ago
The borrow checker is never a significant portion of compile times.
- mattwilsonn888 1y ago
  This is incredibly misleading (technically true maybe) and you know it. Rust has slower compile times for the sake of safety, it's a tradeoff you shouldn't be ashamed of. I didn't narrowly claim the borrow checker (as opposed to the type system or other static analysis) was the sole focus of the tradeoff.
  - shakow 1y ago
    > Rust has slower compile times That's true. > for the sake of safety, That's false though. All deep dives in the topic find that the core issue is the sheer amount of unoptimized IR that is thrown at LLVM, especially due to the pervasive monomorphization of everything.
    - mattwilsonn888 1y ago
      Well it is arguably Rust's worst issue and it has remained it for most of its life. Are you really going to try and convince people that this is completely incidental and not a result of pursuing its robust static contracts? How pedantic should we about about it?
      - steveklabnik 1y ago
        Yes. This is borne out by the numbers. It has nothing to do with being pedantic, it’s basic facts.
      - purplesyringa 1y ago
        It's not about static contracts at all, it's about keeping performance of high-level APIs high. It's all just about templates and generics, as far as I'm aware -- the same problem that plagues C++, except that it's worse in Rust because it's more ergonomic to expose templates in public library APIs in Rust than C++. Well, and also the trait solver might be quite slow, but again, it has nothing to do with memory safety.
      - shakow 1y ago
        > Are you really going to try and convince people that this is completely incidental and not a result of pursuing its robust static contracts? I am, because that's what all the people that explored the question converged on. Now if you have other evidences to bring to the debate, feel free to – otherwise, please stop spreading FUD and/or incompetence.
      - burntsushi 1y ago
        On the one hand, you talk about being upfront and honest about trade-offs. On the other, you yourself are being less that credible by phrasing wild speculation as if they are facts. So... do I as I say, not as I do?

No. It is not an invisible safeguard - it yaps and significantly increases compile time and (a matter of great debate) development effort. It is a helmet, just accept it. Helmets are useful.

rowanG077 1y ago

It is a helmet. But at least it's a helmet in situations where you get into brain cracking accidents multiple times a day. In the end the helmet allows you to get back up and continue your journey compared to when you had no helmet.

mattwilsonn888 1y ago
We're talking about Zig not C. Same argument will apply to Odin. These modern approaches are not languages that result in constant memory-safety issues like you imply.
- pjmlp 1y ago
  Modern as in 1978 and Modula-2 was just made available. Or better yet, modern as 1961 Burroughs released ESPOL/NEWP and C was a decade away to be invented.

steveklabnik 1y ago

The borrow checker is never a significant portion of compile times.

mattwilsonn888 1y ago
This is incredibly misleading (technically true maybe) and you know it. Rust has slower compile times for the sake of safety, it's a tradeoff you shouldn't be ashamed of. I didn't narrowly claim the borrow checker (as opposed to the type system or other static analysis) was the sole focus of the tradeoff.
- shakow 1y ago
  > Rust has slower compile times That's true. > for the sake of safety, That's false though. All deep dives in the topic find that the core issue is the sheer amount of unoptimized IR that is thrown at LLVM, especially due to the pervasive monomorphization of everything.
  - mattwilsonn888 1y ago
    Well it is arguably Rust's worst issue and it has remained it for most of its life. Are you really going to try and convince people that this is completely incidental and not a result of pursuing its robust static contracts? How pedantic should we about about it?
    - steveklabnik 1y ago
      Yes. This is borne out by the numbers. It has nothing to do with being pedantic, it’s basic facts.
    - purplesyringa 1y ago
      It's not about static contracts at all, it's about keeping performance of high-level APIs high. It's all just about templates and generics, as far as I'm aware -- the same problem that plagues C++, except that it's worse in Rust because it's more ergonomic to expose templates in public library APIs in Rust than C++. Well, and also the trait solver might be quite slow, but again, it has nothing to do with memory safety.
    - shakow 1y ago
      > Are you really going to try and convince people that this is completely incidental and not a result of pursuing its robust static contracts? I am, because that's what all the people that explored the question converged on. Now if you have other evidences to bring to the debate, feel free to – otherwise, please stop spreading FUD and/or incompetence.
    - burntsushi 1y ago
      On the one hand, you talk about being upfront and honest about trade-offs. On the other, you yourself are being less that credible by phrasing wild speculation as if they are facts. So... do I as I say, not as I do?