Hacker News new | past | comments | ask | show | jobs | submit login

On the other hand, the Rust code is guaranteed at compile time to be free from buffer overruns, off-by-one errors, and a whole host of other nasties.

I know, I know, the C code you write never has buffer overruns, just like the C code I write never does, well, except that one time, but then I caught it in the debugger during testing and it was easy to fix. Oh, and then that other time, but I caught that one too, and then.....




You forgot about the time you forgot to zero the memory before using it, and it took a week to track down the random junk appearing in you data.


> you forgot to zero the memory before using it

Nah, I did that on purpose because I remember the time I accidentally swapped the 'value' and 'size' parameters of memset, trashing the stack, and so now I go the 'safer' option to just leave things uninitialised. Not to mention the performance increase I get from avoiding a memset that isn't necessary, so long as I'm really, really careful and never make a mistake, which I almost never do.


I love how a type safe memset that distinguished between size types and value types would have fixed your problem (with no run time overhead), but you take this a reason to do even more unsafe stuff that has dubious costs for dubious advantages.

And I cannot tell if you are serious, trolling or sarcastic, because I know people who think this way, think this way is a joke and think this way is the bane of their professional lives.


Not being serious, but joking based on real life things have have bitten me at one point or another, and the mindset of some developers dismissing the benefits of safety and caring about mostly non-existent speed benefits.


> On the other hand, the Rust code is guaranteed at compile time to be free from buffer overruns

No it's not. In this line:

    .zip(&buffer[i - 12..i])
you can just put any indices and it will compile.


But it will not read outside of the buffer. It will panic at runtime instead. That's not a buffer overrun.


It's still an error discovered at runtime. It's one that smacks you in the face instead of silently doing the wrong thing, but it's still found at runtime. I really prefer my errors to be found at compile time, but that's often harder to do...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: