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

Look, I get it, you don't want to give up the "power" of C for the improved memory safety of something else you don't yet understand.

Not quite: I am vehemently against the idea of trading simplicity of C for ultra complexity of Rust, just so I could get some compile time checking, and I will forever be the enemy of that idea.

But you could really simplify your argument to: "I don't care much about safety, so C is fine."

I care very much about safety. But I will not trade simplicity for an ultra complex language like Rust, just so the compiler could do some compile time checking.

Oh, you're a mere mortal like the rest of us.

Buddha was a mere mortal too. However, this programming business is special to me. Computers aren't only my passion. They're my life.

Maybe you're the promised child, the next Buddha, who will usher in a new age of secure C.

And just like all the 33 buddhas, I too am straining and struggling to become one, even if it takes 100,000 years.




> Not quite: I am vehemently against the idea of trading simplicity of C for ultra complexity of Rust

The intricacies of undefined behavior escape a lot of my coworkers. Having to painstakingly explain strict aliasing rules and what constitutes a sequence point (or doesn't) isn't "simple". Even basic multithreading support as recently as C99 required third party libraries, and compiler extensions - if only to prevent the unexpected reordering of code by the optimizer.

In practice, this is complex enough that I resort to third party tools to try and manage these and other complexities in the form of static analysis, aided by even more compiler extensions. I retrofit them to existing code, and then it points out where shared data is accessed without being protected by locking the appropriate mutex - and then I smile, for I've seen weeks sunk debugging such bugs, and I've spent 10 minutes to not only catch one such bug, and prevent them in the future for this code. Iterator invalidation checks? Sign me up!

Rust's lifetime management and borrow checking are, frankly, a much more comprehensive and unified way of doing a lot of what I was already doing in C and C++ code. We end up disagreeing on which language is the simple one, and which language is the complex one.

> I care very much about safety. But I will not trade simplicity for an ultra complex language like Rust, just so the compiler could do some compile time checking.

Do your actions agree with your words? I've listed several of the things I've done to wrangle with the problem of safety - not a comprehensive list, mind you, but a good start. Perhaps you go even further, and use one of the "safe" C subsets such as MISRA C?

EDIT:

> Yes, C has no safety. If my code has a hole, it will be noone's fault but my own. And that's the way I like it: [...]

Are you sure you care very much about safety?


Rust's lifetime management and borrow checking are, frankly, a much more comprehensive and unified way of doing a lot of what I was already doing in C and C++ code. We end up disagreeing on which language is the simple one, and which language is the complex one.

Yes, we disagree, and vehemently at that. I think borrowing is one of the most overcomplicated things in Rust, and is one of the major reasons why I am against it. You hit the nail on the head.

Are you sure you care very much about safety?

Yes. Every piece of code I write in C, when I write it in C, is run through a debugger before it is put in production, because I don't trust my code and I don't trust myself. In fact, I don't release anything in any programming language without having debugged it first, even when it appears to function correctly. It's still simpler than Rust!




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

Search: