3 ms·

This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. New

by p-e-w 4y ago

This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. New projects written in C are being started every day. This is the exact equivalent of physicians continuing to use unsafe medical procedures, and what's worse, many of those engineers defend their dangerous practices by claiming there is no real danger in the first place if the programmer is "smart enough".

jstimpfle 4y ago
I'm one of those people who still write in C, and I like the experience. I've had a lot of fun, and haven't been burned by it, although statistically it's likely that I will be at some point. I've tried a lot of languages in the past, and am currently not willing to dive into a whole new ecosystem, re-learn all the best practices, and unlearn what's worked very well for me with sometimes no good replacement. Best practice for Rust seems to be to avoid linked lists for example. I don't know what's the safe replacement for memset and memcpy to anonymous data structures (void pointers -- generic code) but I have a sense that it is more painful. The general recommendations seem to be to switch to different, more complicated datastructures with more failure modes, or to put boxes and Arcs around things. I don't think this fits me - I like the feeling of understanding what I'm doing, and once in a while coming up with something that compiles and runs fast and robustly. If you can do that in Rust, good for you. Another part is that it still seems easier to interface with existing ecosystems in C. I tried writing some Win32 Rust code once in an evening and I have to admit I failed. Maybe I picked the wrong bindings library or whatever. At this point in my life, I have little patience to spend my time like this. I appreciate the work that is being done, and I feel it's not unlikely that at some point we all will switch. At this point though I feel I'm way more productive staying in my current habitat. And that's not only on me, but also that the ecosystem and developed practices likely are not quite ready for a complete switch. Comparing the investment to simply washing hands and putting on gloves or following a checklist as a surgeon feels unfair to me.
- ajuc 4y ago
  It's not even about languages. Just using valgrind or sth similar as a part of CI would solve A LOT of issues.
- cjg 4y ago
  Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise. Luckily you don't have to, there's one in the standard library: https://doc.rust-lang.org/std/collections/struct.LinkedList.html https://doc.rust-lang.org/std/collections/struct.LinkedList.... The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.
  - jstimpfle 4y ago
    This isn't an intrusively linked list. Probably not the Clone trait but the Copy trait.
  - steveklabnik 4y ago
    > The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone. If you type "memcpy" into the documentation search, rustdoc will point you to * https://doc.rust-lang.org/stable/std/primitive.slice.html#method.copy_from_slice https://doc.rust-lang.org/stable/std/primitive.slice.html#me... * https://doc.rust-lang.org/stable/std/intrinsics/fn.copy_nonoverlapping.html https://doc.rust-lang.org/stable/std/intrinsics/fn.copy_nono... (Though it should really point to the reexport at https://doc.rust-lang.org/stable/std/ptr/fn.copy_nonoverlapping.html https://doc.rust-lang.org/stable/std/ptr/fn.copy_nonoverlapp... ) The latter will also mention * https://doc.rust-lang.org/stable/std/ptr/fn.copy.html https://doc.rust-lang.org/stable/std/ptr/fn.copy.html
  - fiedzia 4y ago
    > Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise Implementing linked list in any language that is not memory-safe is challenging because of safety issues. Rust just points it out.
- 4y ago
vineyardmike 4y ago
> This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. > New projects written in C are being started every day. But it is mostly about existing software, even if its not about replacing existing software. I write C++ code every day. I hate it, and I'd rather not. But I use C++ libraries written by my teammates, and reference implementations in prior C++ work in our past projects, and have a set-up C++ toolchain, and my company even has all sorts of written C++ docs and style guides and linters and macros and ... and ... Even if we wanted to stop, there's so much extra stuff to consider. I get your point, <<why start a new thing knowing there's a better way?>> and I would want to stop using c++ but most software isn't one-and-done like a surgery. It is a continuous commitment and ongoing operation, it is the tools used, and the knowledge learned, and the libraries built. > This is the exact equivalent of physicians continuing to use unsafe medical procedures Plenty of platforms don't support rust. Just because you've improved knee surgery, doesn't mean it works on an elbow... yet. And sometimes you still gotta perform surgery on elbows. > if the programmer is "smart enough". Can't defend this, but tbh I've never heard it.
- simiones 4y ago
  > > if the programmer is "smart enough". > Can't defend this, but tbh I've never heard it. Take a look at this comment: https://news.ycombinator.com/item?id=33824934 https://news.ycombinator.com/item?id=33824934 > Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. It is a somewhat common attitude in this type of thread.
  - josefx 4y ago
    > It is a somewhat common attitude in this type of thread. Except the safety features are often a lot easier to use than the original C isms that tend to cause the most issues. So it is less an issue of smart and more one of bad habits. C strings instead of std::string, plain arrays instead of std::vector, implicit ownership instead of smart pointers, ... .
    - 4y ago
peoplefromibiza 4y ago
> There are plenty of engineers that argue for continuing to use memory-unsafe programming languages And why do you think it's wrong, per se? > This is the exact equivalent of physicians continuing to use unsafe medical procedures You mean with different safety tradeoffs? Because what you propose is exactly like forcing very expert physicians to switch to a procedure they are novice of and that it's not been battle tested like the old one, that proved to be very effective in most cases. It's the same reason why patients prefer to be treated with established procedures and to undergo experimental treatments they need to sign a document that proves their informed consent.

by p-e-w 4y ago

jstimpfle 4y ago

I'm one of those people who still write in C, and I like the experience. I've had a lot of fun, and haven't been burned by it, although statistically it's likely that I will be at some point. I've tried a lot of languages in the past, and am currently not willing to dive into a whole new ecosystem, re-learn all the best practices, and unlearn what's worked very well for me with sometimes no good replacement. Best practice for Rust seems to be to avoid linked lists for example. I don't know what's the safe replacement for memset and memcpy to anonymous data structures (void pointers -- generic code) but I have a sense that it is more painful. The general recommendations seem to be to switch to different, more complicated datastructures with more failure modes, or to put boxes and Arcs around things. I don't think this fits me - I like the feeling of understanding what I'm doing, and once in a while coming up with something that compiles and runs fast and robustly. If you can do that in Rust, good for you. Another part is that it still seems easier to interface with existing ecosystems in C. I tried writing some Win32 Rust code once in an evening and I have to admit I failed. Maybe I picked the wrong bindings library or whatever. At this point in my life, I have little patience to spend my time like this. I appreciate the work that is being done, and I feel it's not unlikely that at some point we all will switch. At this point though I feel I'm way more productive staying in my current habitat. And that's not only on me, but also that the ecosystem and developed practices likely are not quite ready for a complete switch. Comparing the investment to simply washing hands and putting on gloves or following a checklist as a surgeon feels unfair to me.

ajuc 4y ago
It's not even about languages. Just using valgrind or sth similar as a part of CI would solve A LOT of issues.
cjg 4y ago
Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise. Luckily you don't have to, there's one in the standard library: https://doc.rust-lang.org/std/collections/struct.LinkedList.html https://doc.rust-lang.org/std/collections/struct.LinkedList.... The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.
- jstimpfle 4y ago
  This isn't an intrusively linked list. Probably not the Clone trait but the Copy trait.
- steveklabnik 4y ago
  > The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone. If you type "memcpy" into the documentation search, rustdoc will point you to * https://doc.rust-lang.org/stable/std/primitive.slice.html#method.copy_from_slice https://doc.rust-lang.org/stable/std/primitive.slice.html#me... * https://doc.rust-lang.org/stable/std/intrinsics/fn.copy_nonoverlapping.html https://doc.rust-lang.org/stable/std/intrinsics/fn.copy_nono... (Though it should really point to the reexport at https://doc.rust-lang.org/stable/std/ptr/fn.copy_nonoverlapping.html https://doc.rust-lang.org/stable/std/ptr/fn.copy_nonoverlapp... ) The latter will also mention * https://doc.rust-lang.org/stable/std/ptr/fn.copy.html https://doc.rust-lang.org/stable/std/ptr/fn.copy.html
- fiedzia 4y ago
  > Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise Implementing linked list in any language that is not memory-safe is challenging because of safety issues. Rust just points it out.
4y ago

vineyardmike 4y ago

> This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. > New projects written in C are being started every day. But it is mostly about existing software, even if its not about replacing existing software. I write C++ code every day. I hate it, and I'd rather not. But I use C++ libraries written by my teammates, and reference implementations in prior C++ work in our past projects, and have a set-up C++ toolchain, and my company even has all sorts of written C++ docs and style guides and linters and macros and ... and ... Even if we wanted to stop, there's so much extra stuff to consider. I get your point, <<why start a new thing knowing there's a better way?>> and I would want to stop using c++ but most software isn't one-and-done like a surgery. It is a continuous commitment and ongoing operation, it is the tools used, and the knowledge learned, and the libraries built. > This is the exact equivalent of physicians continuing to use unsafe medical procedures Plenty of platforms don't support rust. Just because you've improved knee surgery, doesn't mean it works on an elbow... yet. And sometimes you still gotta perform surgery on elbows. > if the programmer is "smart enough". Can't defend this, but tbh I've never heard it.

simiones 4y ago
> > if the programmer is "smart enough". > Can't defend this, but tbh I've never heard it. Take a look at this comment: https://news.ycombinator.com/item?id=33824934 https://news.ycombinator.com/item?id=33824934 > Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. It is a somewhat common attitude in this type of thread.
- josefx 4y ago
  > It is a somewhat common attitude in this type of thread. Except the safety features are often a lot easier to use than the original C isms that tend to cause the most issues. So it is less an issue of smart and more one of bad habits. C strings instead of std::string, plain arrays instead of std::vector, implicit ownership instead of smart pointers, ... .
  - 4y ago

peoplefromibiza 4y ago

> There are plenty of engineers that argue for continuing to use memory-unsafe programming languages And why do you think it's wrong, per se? > This is the exact equivalent of physicians continuing to use unsafe medical procedures You mean with different safety tradeoffs? Because what you propose is exactly like forcing very expert physicians to switch to a procedure they are novice of and that it's not been battle tested like the old one, that proved to be very effective in most cases. It's the same reason why patients prefer to be treated with established procedures and to undergo experimental treatments they need to sign a document that proves their informed consent.