Hacker News new | past | comments | ask | show | jobs | submit login

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.




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....

The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.


> 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#me...

* 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_nonoverlapp... )

The latter will also mention

* https://doc.rust-lang.org/stable/std/ptr/fn.copy.html


> 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.


This isn't an intrusively linked list.

Probably not the Clone trait but the Copy trait.


My limited experience with Rust was that I need to know exactly what I want to do in the code and compiler is there to make sure I write that intent as actual code, not my assumptions about how the code will work.

I don't feel that I am less in control, just that all of that needs to be put in code and not just go "okay, I know this part don't need a lock coz I will never call it concurrently" and hope for best.

Even writing for embedded (as in no os, tens of kilobytes of RAM microcontrollers) haven't been too bad althought I haven't managed to convince borrow checker to borrow non-contigous block of bits from a register yet... althought that's what unsafe{} is for after all

> Comparing the investment to simply washing hands and putting on gloves or following a checklist as a surgeon feels unfair to me.

The closer one would be "read that 300 pages of how to do stuff safely and apply it". Once you get into good habits it's not a problem but investment is there


It's not even about languages. Just using valgrind or sth similar as a part of CI would solve A LOT of issues.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: