Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

humprog.org

Post reply on HN
Print view View original

11–20 of 118 posts

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#11

Post by adrianN »

stevenhuang wrote: post #10
moshegramovsky wrote: post #9

Earlier quoted context omitted.

Well I guess it's a good thing no one ever had a double free in C :) > They mean you can never tell what `delete` does. Can you elaborate on this? A destructor is a function that's built into an object. It's really not more complicated than that. If malloc/free are functions that should be used in pairs, then the constructor/destructor pair tries to provide a convenient and structured way to know where malloc/free go…

Cases can arise where ownership of objects are not clear (which is a separate issue) but when they do occur, you can have a custom destructor that frees a lot of other objects, and then these other objects may in fact be "owned" elsewhere. Somewhere down the line these other objects are freed again, causing double free.

How would malloc/free be better in that situation?

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#12

Post by scaredginger »

stevenhuang wrote: post #10
moshegramovsky wrote: post #9

Earlier quoted context omitted.

Well I guess it's a good thing no one ever had a double free in C :) > They mean you can never tell what `delete` does. Can you elaborate on this? A destructor is a function that's built into an object. It's really not more complicated than that. If malloc/free are functions that should be used in pairs, then the constructor/destructor pair tries to provide a convenient and structured way to know where malloc/free go…

Cases can arise where ownership of objects are not clear (which is a separate issue) but when they do occur, you can have a custom destructor that frees a lot of other objects, and then these other objects may in fact be "owned" elsewhere. Somewhere down the line these other objects are freed again, causing double free.

This sounds much more like a case of awful design than destructors being problematic

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#14

Post by froh »

Joel_Mckay wrote: post #7
rootw0rm wrote: post #3

I love C. It's what I learned after learning MASM style Intel assembly. I have a project still at the planning stage. I have many Rust crates lined up. So far I really like the bits of Rust I have learned. C plus generics? Sign me up! But damn, after coming from really awesome IDEs like Visual Studio, it just seems like it's taking me forever to make progress. Right now I'm asking myself, does Rust save me time in th…

The use-case for Rust is not the same as C. In general, C is a better option if you find you are escaping to macro defined Assembly or other memory ops (glib back-ported data structures for C highly recommended). Rust likes to keep unsafe operations organized, but is a persistent pain if a problem scope requires many "unsafe" operations. I'd wager Rust will end up like Boost... really cool.. but too chaotic to trust…

I don't get the 10 months part. is it some reference?

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#15

Post by mlindner »

Joel_Mckay wrote: post #7
rootw0rm wrote: post #3

I love C. It's what I learned after learning MASM style Intel assembly. I have a project still at the planning stage. I have many Rust crates lined up. So far I really like the bits of Rust I have learned. C plus generics? Sign me up! But damn, after coming from really awesome IDEs like Visual Studio, it just seems like it's taking me forever to make progress. Right now I'm asking myself, does Rust save me time in th…

The use-case for Rust is not the same as C. In general, C is a better option if you find you are escaping to macro defined Assembly or other memory ops (glib back-ported data structures for C highly recommended). Rust likes to keep unsafe operations organized, but is a persistent pain if a problem scope requires many "unsafe" operations. I'd wager Rust will end up like Boost... really cool.. but too chaotic to trust…

I'm not sure if I agree with any statement of the form "The use-case for Rust is not the same as foo." for any foo where Rust is replacing a language that replaced foo.

Rust is replacing C++ in several well documented places, however C++ itself was a replacement for C in many places. So by definition the use-case for Rust overlaps the use-case for C.

Arguments like this sound like old arguments that were re-told to me by my father where people argued that C couldn't replace the use case for Algol at the University of Michigan MTS system. (Assuming I'm remembering the second-hand argument right. I'm a second generation software engineer.)

Also, there's nothing of note in the last 10 months about Rust that's different from the 10 months before that.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#17

Post by ihatepython »

adrianN wrote: post #11
stevenhuang wrote: post #10

Earlier quoted context omitted.

Cases can arise where ownership of objects are not clear (which is a separate issue) but when they do occur, you can have a custom destructor that frees a lot of other objects, and then these other objects may in fact be "owned" elsewhere. Somewhere down the line these other objects are freed again, causing double free.

How would malloc/free be better in that situation?

I don't know, but when I use C, I like to statically allocate everything if at all possible, I don't free() anything, I let the OS clean everything up at exit(). A lot of the small Unix utilities don't necessarily need dynamic memory allocation IMO

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#18

Post by mlindner »

This entire article seems to amount to "I am used to C, thus I don't see the problem with C." which is a fine position to have, but it's a perspective unique to the writer and others like him. It doesn't apply to people learning new languages that aren't C.

Also several statements about how C must be used because somehow it's closer to the real world/hardware than other languages. Which is easily shown to be false given that hardware designers have had bend backwards and into contorted shapes to emulate the hardware environment that C was originally created to work against. This great article is a nice rebuttal of that: C Is Not a Low-level Language: Your computer is not a fast PDP-11. https://queue.acm.org/detail.cfm?id=3212479

These types of arguments feel like they come from people who don't realize how much the compiler reworks your code to make it act like it does what you told it to do.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#19

Post by spacechild1 »

torstenvl wrote: post #5
adrianN wrote: post #4

Earlier quoted context omitted.

The use cases where C is the best option are probably limited to exotic platforms that don't have compilers for better languages. There aren't many targets were you can't at least use C++.

Your comment seems to assume C++ is a better, safer language than C. I know a number of people who would sharply question that assumption. I for one really hate destructors. They mean you can never tell what `delete` does. I remember a nasty double-free bug I had because of that.

First off, new/delete are only used for objects that are allocated on the heap. Even then, modern C++ has RAII wrappers such as std::unique-ptr. You should only need new/delete in rare cases.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#20

Post by waiseristy »

The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort.

Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one

Post reply on HN