Hacker News Reader

Comment by assimpleaspossi | Hacker News Reader

>I have to work more slowly, cautiously, and remember things

I think that should be a good thing.

It depends on what I’m being slow and cautious about. Imagine a programming language that is identical to C, but every prime-numbered line is ignored. In such a language, I would be cautious to add or remove lines, slowly and cautiously remembering which line numbers to avoid. It wouldn’t provide any benefit, as I’d be paying attention to line numbers instead of paying attention to null checks, or integer overflow.

In the same way, C imposes an extra burden compared to other languages. If I declare a std::vector in C++, or a Vec in Rust, it will be deallocated when the scope is exited. But in C, every malloc() requires a call to free(). It requires extra effort for no benefit.

This is a far better way of putting what I tried to say, thank you.

There is absolutely a benefit, but it doesn't sound like one to you: it explicitly requires you to know that you're actually doing something with memory, which rapidly deteriorates as a concept for developers once they no longer have to be cognizant of the fact that they are indeed actually using it.

I prefer a world where people actually think about the resources they're using.

But does that benefit actually exist? The approach of languages like C++ or Rust isn't to hide memory in the way a GC'd environment like Java or Python does (although C++ does have historical baggage with its copy constructors)--this feels to me like it's the same problem I mentioned in my first comment, that you're focused on contrasting C with managed languages and ignoring the space of non-managed languages. And, anecdotally, from what I've seen perusing various Rust crates, my sense is that too many Rust programmers actually spend too much time worrying about their memory usage, designing extensive and cumbersome zero-copy interfaces when, no really, you should just copy that 5-byte string to your own storage.

I don't see how having to remember to always add in calls to free, with the cost of using more memory if you forget to do so, is really supposed to help you minimize your memory usage. That's the main difference we're talking about here...

Remembering to use free() is a lot easier than remembering the inner workings of each and every destructor of each and every object you use.

Will destroying this window free the memory for this font instance? Will destroying this DOCX processing object close the file? Who knows?

But when the rule is just to clean up after yourself, it's a lot easier to remember.

In C, declaration != heap allocation. And this is a very important detail because implementing something like "deallocation when the scope is exited" adds complexity to the language; more things and more rules you now have to remember.

> It requires extra effort for no benefit.

There is a benefit, although it may not be useful for your use case. In that situation, I agree with you -- use a different language.

I find it interesting that so many comments here criticizing C (and a couple of other languages) seem to be taking the stance that "if it isn't good for every kind of task, it isn't good for any kind of task".

Every language both rocks and sucks, depending on what you're doing with it. There is no One Ring to Rule Them All. That's why we have so many different languages -- we should be choosing the one that fits the job at hand.

This is why I think holy wars over languages are always ridiculous. Any given language may be a terrible choice for a particular job. That's not a fault of the language, it's just a sign that language is the wrong tool. Use a different tool.

Humans build tools to help us achieve things. No good comes from making me manually remember things a machine could easily check for me.

I doubt you crafted the HTTP call to post this comment by hand, even if you could. I could. I don't want to. That's why tools exist.

Reply on news.ycombinator.com