5 ms·

You're not going to convince C programmers simply by beseeching them. The article is missing an entire component: the argument for Rust. There needed to be ex

You're not going to convince C programmers simply by beseeching them. The article is missing an entire component: the argument for Rust. There needed to be examples of C programs that one may write that are actually unsafe and of how Rust addresses that. There needed to be a discussion on the performance of Rust, and of its ability to call into C without overhead (or to be called by C without overhead). Everyone already knows what the problems of C are, what they need to know is what the alternatives offer and how in the end you are not giving up too much.

coldtea 11y ago
>* The article is missing an entire component: the argument for Rust. There needed to be examples of C programs that one may write that are actually unsafe* Every C programmer already knows what kind of C issues exist, and how with C you can screw up things and what operations are unsafe. It's not like he's saying something novel that will leave C programmers scratching their head as to the value of a safer language. >There needed to be a discussion on the performance of Rust, and of its ability to call into C without overhead He suggested they look at it, and he gave the basic 10,000 foot overview. It's not like C programmers (an industry with millions) will convert simply if some random blog post gave more specific examples...
ci5er 11y ago
I really like the promise of Rust. I mostly like its design. But, for myself, I notice this: Writing Rust programs (vs. writing C programs) correctly is hard! N.B. This might be an old dog new tricks thing. I automatically structure my programs (be they rendering engines, or computation/numerical simulations or even agent-based simulations) where allocating and freeing memory from/to pools just isn't that hard. I don't really think about it. I just throw together my code, compile it and run it. Of course, I make many (many!) silly/stupid mistakes during the course of development, but failing to free a pointer is rarely one of them. Now I loop back to your point. (Sorry I took the long way) > Everyone already knows what the problems of C are, what they need to know is what the alternatives offer and how in the end you are not giving up too much. I know what the problems of C are. I am aware of the alternatives. But the problems of C don't seem to be overwhelming enough to bother throwing away and constructing an entirely new tool-chain and support system on whatever your platform is. That was a pretty bold statement, and I would invite a response. I would like to think that we, as an industry, are not just implementing new language ecosystems because we can't be bothered to free our pointers...
- dbaupp 11y ago
  > Writing Rust programs (vs. writing C programs) correctly is hard! To be clear: getting Rust programs past the compiler is much harder that C programs: C doesn't incorporate much type-system/static checking so a lot more gets past the compilers. But writing truly correct C programs (i.e. don't crash horribly) is a harder task, as there's no computer assistance for avoiding large classes of possible bugs. > failing to free a pointer is rarely one of them > we can't be bothered to free our pointers Solving this "problem" is not the goal of Rust. Rust aims to avoid undefined behaviour by default, e.g. derefencing invalid pointers, use-after-free, iterator invalidation are statically ensured to never happen, unless you opt-in at specific locations via `unsafe`. Cleaning up memory automatically is a nice feature, but the main draw card and the reason Rust might actually be interesting is that Rust offers memory safety without garbage collection. In any case, I think you're being overly glib about the problems of C: it's so so easy to have a program that exhibits undefined behaviour, and so is theoretically operating with no restrictions.
  - ci5er 11y ago
    > In any case, I think you're being overly glib about the problems of C: In short form, here, without a doubt. > it's so so easy to have a program that exhibits undefined behaviour, and so is theoretically operating with no restrictions. I've run into this. A lot! It was almost always my fault. One notable exception was back when I used to do a fair amount of with GP (Genetic Programming -- evolving large populations of small programs). The system was shockingly adept at finding/exploiting edge-cases and exploiting them for advantage.
  - ci5er 11y ago
    > In any case, I think you're being overly glib about the problems of C: In short form, here, without a doubt. > it's so so easy to have a program that exhibits undefined behaviour, and so is theoretically operating with no restrictions. I've run into this. A lot! It was almost always my fault. One notable exception was back when I used to do a fair amount of with GP (Genetic Programming -- evolving large populations of small programs). The system was shockingly adept at finding/exploiting edge-cases and exploiting them for advantage.

coldtea 11y ago

>* The article is missing an entire component: the argument for Rust. There needed to be examples of C programs that one may write that are actually unsafe* Every C programmer already knows what kind of C issues exist, and how with C you can screw up things and what operations are unsafe. It's not like he's saying something novel that will leave C programmers scratching their head as to the value of a safer language. >There needed to be a discussion on the performance of Rust, and of its ability to call into C without overhead He suggested they look at it, and he gave the basic 10,000 foot overview. It's not like C programmers (an industry with millions) will convert simply if some random blog post gave more specific examples...

ci5er 11y ago

I really like the promise of Rust. I mostly like its design. But, for myself, I notice this: Writing Rust programs (vs. writing C programs) correctly is hard! N.B. This might be an old dog new tricks thing. I automatically structure my programs (be they rendering engines, or computation/numerical simulations or even agent-based simulations) where allocating and freeing memory from/to pools just isn't that hard. I don't really think about it. I just throw together my code, compile it and run it. Of course, I make many (many!) silly/stupid mistakes during the course of development, but failing to free a pointer is rarely one of them. Now I loop back to your point. (Sorry I took the long way) > Everyone already knows what the problems of C are, what they need to know is what the alternatives offer and how in the end you are not giving up too much. I know what the problems of C are. I am aware of the alternatives. But the problems of C don't seem to be overwhelming enough to bother throwing away and constructing an entirely new tool-chain and support system on whatever your platform is. That was a pretty bold statement, and I would invite a response. I would like to think that we, as an industry, are not just implementing new language ecosystems because we can't be bothered to free our pointers...

dbaupp 11y ago
> Writing Rust programs (vs. writing C programs) correctly is hard! To be clear: getting Rust programs past the compiler is much harder that C programs: C doesn't incorporate much type-system/static checking so a lot more gets past the compilers. But writing truly correct C programs (i.e. don't crash horribly) is a harder task, as there's no computer assistance for avoiding large classes of possible bugs. > failing to free a pointer is rarely one of them > we can't be bothered to free our pointers Solving this "problem" is not the goal of Rust. Rust aims to avoid undefined behaviour by default, e.g. derefencing invalid pointers, use-after-free, iterator invalidation are statically ensured to never happen, unless you opt-in at specific locations via `unsafe`. Cleaning up memory automatically is a nice feature, but the main draw card and the reason Rust might actually be interesting is that Rust offers memory safety without garbage collection. In any case, I think you're being overly glib about the problems of C: it's so so easy to have a program that exhibits undefined behaviour, and so is theoretically operating with no restrictions.
- ci5er 11y ago
  > In any case, I think you're being overly glib about the problems of C: In short form, here, without a doubt. > it's so so easy to have a program that exhibits undefined behaviour, and so is theoretically operating with no restrictions. I've run into this. A lot! It was almost always my fault. One notable exception was back when I used to do a fair amount of with GP (Genetic Programming -- evolving large populations of small programs). The system was shockingly adept at finding/exploiting edge-cases and exploiting them for advantage.
- ci5er 11y ago
  > In any case, I think you're being overly glib about the problems of C: In short form, here, without a doubt. > it's so so easy to have a program that exhibits undefined behaviour, and so is theoretically operating with no restrictions. I've run into this. A lot! It was almost always my fault. One notable exception was back when I used to do a fair amount of with GP (Genetic Programming -- evolving large populations of small programs). The system was shockingly adept at finding/exploiting edge-cases and exploiting them for advantage.