#i have yet to find a language as readable as hask. i have yet to find a language as fun to work in as rust.

[sunless-not-sinless]

#and you CAN write memory-unsafe rust code; it just has to be within an “unsafe” block#so you DO have access to some C-like constructs if you Really Need to do smth like that#maybe thats useful for the linux kernel or w/e but i certainly havent needed to use it. rust's normal stuff works just fine

just expanding on this, it being in a separate block means that if anything fucks up then theres only a small area of code to search for. if you get a segfault in C, then any bit of code could do that. if you get a segfault in rust then only* unsafe code can do that. unsafe can also be used when you as the programmer knows something the compiler doesnt.

basic rust:

rust makes sure that in "safe" rust if some data can mutate, there can only be one consumer at a time. you dont want x to change while something else prints x. you dont want race conditions.

rust also deals with mutability. by default it is not possible to mutate some data, you have to mark it as mutable. and again, you cannot have multiple mutable references to the same data.

slices. in rust a slice is a datatype that is effectively an array. a continuous block of data. an array is of fixed size, a vec can grow and shrink, and a slice is generic and works with both of them.

the unsafe code part:

... sometimes this "one mutable reference per bit of data" is overly restrictive! lets say you have some slice, and you want to split it in two. uhhh i dont know, lets say its sorted and you want to split it into two arrays for negatives and positives/zeros, and you want both of these two new arrays to be mutable. well if we design a function to split arr in two, it would need to return (&mut [T], &mut [T]). two separate mutable slices. but the data is owned by one variable. we know we can split this variable up, but the compiler doesnt! it just sees lots of data owned by one variable!

so any function splitting into multiple mutable parts needs unsafe code to get around this!

this example was taken from the book.

*although it would be great if segfaults were guaranteed to be only in unsafe code, im not sure it would be possible to *guarantee* this. the compiler devs are human and mistakes sometimes slip through. e.g. cve-rs was a fun project that allowed for so much bullshit, but the bug it exploited has been patched.

what the devs can guarantee, however, is that you wont get segfaults in safe code unless you specifically look for them. if youre just writing code and not trying to get a segfault, you wont get segfaults in safe code.

also when i say segfaults i mean them and a whole host of other memory corruption errors. use after frees, double frees, etc.

If any Haskell and or Rust fans follow me, give me 1 good reason to learn them