3 ms·

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!

by ci5er 12y 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 12y 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 12y 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 12y 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.
seanwilson 12y ago
I'm guessing that the cases where the Rust program is hard to write it's because it's actually difficult to reason why the program is correct and the C code is likely to be buggy anyways? Or was it a problem with Rust?
- kibwen 12y ago
  It could be either. By definition, a static type system must sometimes reject completely valid programs that it cannot prove are type-safe. That said, for people coming from C/C++, the biggest initial stumbling blocks seem to be that Rust simply rewards different approaches to structuring your programs, which take time to internalize.

by ci5er 12y ago

dbaupp 12y 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 12y 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 12y 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.

seanwilson 12y ago

I'm guessing that the cases where the Rust program is hard to write it's because it's actually difficult to reason why the program is correct and the C code is likely to be buggy anyways? Or was it a problem with Rust?

kibwen 12y ago
It could be either. By definition, a static type system must sometimes reject completely valid programs that it cannot prove are type-safe. That said, for people coming from C/C++, the biggest initial stumbling blocks seem to be that Rust simply rewards different approaches to structuring your programs, which take time to internalize.