News for hackers. Stuff that matters.
Re:Memory Safe Languages in Android 13 by jstimpfle on Friday December 02, 2022 @03:36AM (#33828198)
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'm currently not ready 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.

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

Re:Memory Safe Languages in Android 13 by ajuc on Friday December 02, 2022 @04:47AM (#33828603)
It's not even about languages. Just using valgrind or sth similar as a part of CI would solve A LOT of issues.
Re:Memory Safe Languages in Android 13 by cjg on Friday December 02, 2022 @04:52AM (#33828626)
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.

Re:Memory Safe Languages in Android 13 by jstimpfle on Friday December 02, 2022 @07:04AM (#33829439)
This isn't an intrusively linked list.

Probably not the Clone trait but the Copy trait.

Re:Memory Safe Languages in Android 13 by steveklabnik on Friday December 02, 2022 @09:29AM (#33830819)
> 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

Re:Memory Safe Languages in Android 13 by fiedzia on Friday December 02, 2022 @10:17AM (#33831594)
> 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.

Re:Memory Safe Languages in Android 13 by ilyt on Friday December 02, 2022 @06:43AM (#33829255)
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