Hacker News Reader

Comment by endorphine | Hacker News Reader

I guess parent argues that:

  - humans have a track-record of writing memory bugs

  - memory-safe languages prevent such by construction

Therefore, what's the justification of not using a memory-safe language (as opposed to an unsafe one)?

View on HN

> what's the justification of not using a memory-safe language

Use Go, Java or Fil-C, and memory safety is achieved at the expense of runtime performance. Tracing garbage collectors make your programs run slower and use more RAM.

With Rust you pay with complexity. Rust has new, weird syntax (lifetimes, HRTB, etc) and invisible borrow checker state that you've gotta understand and keep track of while programming. Rust is a painful language to learn, because lots of seemingly valid programs won't pass the borrow checker. And it takes awhile to internalise those rules.

I personally think the headache of rust is worth it. But I can totally understand why people come to the opposite conclusion.

> because lots of seemingly valid programs won't pass the borrow checker

Some straight-up valid programs as well

Rusts memory safety constructs do also impose a (much smaller) runtime performance penalty. Every Arc / Rc is a memory safe abstraction with runtime cost since rust has no way to prove cyclic reference graphs are safe at compile time.

Interop.

Reply on news.ycombinator.com