Hacker News new | ask | show | jobs
by sshine 2 days ago
> Given the roughly 30% overhead of overflow checks, I think restricting them to debug builds is a reasonable tradeoff. I can also see an argument for using wrap on overflow even in debug builds for consistency and simplicity.

I don’t understand the sentiment to want different behaviour for overflow in debug and release mode.

You want to catch overflows because they’re thought of as errors, but not in production. In production you just want silent failure?

Rust has a number of specialised integer operations (overflowing, saturating) that are slightly less ergonomic (they’re not literally called ‘+’ etc.). So we’re only really arguing whether we should be safe or performant by default, when we don’t care to be explicit.

1 comments

In production you generally want your code to not be 1.5x-2x slower than C/C++, otherwise people will ditch your whole language with all its other benefits in pursuit of performance.

There's a lot of safe but slow languages, Rust is trying incredibly hard to be a safe language that is still seen to be in that general C/C++ ballpark of performance.