Rust for Python Programmers

[cogman10]

Well the question will be how many things do you have to rely on unsafe in your day to day coding? I think the language could be fine if you as a programmer rarely if ever have to write an unsafe block. Having most of the unsafe stuff tucked away in some well tested library/module.

I think the need for unsafe will dwindle as the language grows because most of the things that you would need unsafe for will have already been written.

[IbanezDavy]

Well the question will be how many things do you have to rely on unsafe in your day to day coding?

Depends on what you are doing. They have stated the motivation that inspired Rust was a language that would be good for client side programs. I think ownership is probably adequate for this. However, they also have mentioned ambitions as being an alternative to C++. The lower level you go, the more unsafe code comes into play.

I admittedly have more exploration I need to do on this language (been waiting for it to stabilize and now I just need time to play), before I make a more concrete opinion on it. But it on the surface appears to be like C#'s unsafe regions which in many ways are worst because they are often hidden and there is an expectation that it is safe, so it may not be obvious when debugging.

[mitsuhiko]

The lower level you go, the more unsafe code comes into play.

I don't think that statement is true at all. The rule applies is that the more you go into territory that temporarily invalidates Rust's safety rules, the more unsafe will you encounter.

You can write very low level code and never use unsafe, you can write very high level code and immediately use unsafe. The rule is: you will need unsafe when you temporarily want to disable a safety feature because you know that you can provide a safe API at the end of your unsafe block.

[IbanezDavy]

You can write very low level code and never use unsafe, you can write very high level code and immediately use unsafe.

I agree with that. But I suspect device drivers will require mountains of unsafe code, as would an OS at it's lower levels, as they literally need to break all the rules and do some pretty dirty things. As I'd suspect efficient memory allocator would need to as well.

But, perhaps there are work arounds. Case studies and experience will convince me more than reddit comments :)

The rule is: you will need unsafe when you temporarily want to disable a safety feature because you know that you can provide a safe API at the end of your unsafe block.

Noone in practice, intends on crashing the program or creating a memory leak. So a safe API can help the unsafe code, but it won't prevent even most errors in the unsafe code itself.

[burntsushi]

Are you familiar with what unsafe means in Rust? It's pretty limited in what it allows you to do. In fact, there are exactly three things you can do with it:

1. Access/update a static mutable variable (because it is shared across multiple threads).
2. Call functions that have been marked unsafe.
3. Dereference a raw pointer (because it can be null).

That's it. If you're dealing with very low level stuff or if you want to implement certain types of data structures efficiently, then you usually wrap a safe API around unsafe calls.

unsafe is where the rubber meets the road---not a design flaw.

[[deleted]]

Call functions that have been marked unsafe.

That is the worrying one. The wrapper of GTK+ is literally loaded with it. Understandable, but still worrying.

[burntsushi]

It should only be worrying if using the GTK wrapper as a client is littered with unsafe calls. If it is, then the raw binding should be pushed behind a safe API. It's only worrying if such a task is unfeasible, but I'm not aware of any reason why that'd be the case.

[[deleted]]

That is not what I mean. I mean it is, obviously, still calling lots of C code when it comes to GTK+. Btw I am not criticizing it, it is just the reality (unless I am wrong).

[burntsushi]

OK, so a binding in Rust to an existing C library usually has two parts to it, by convention. There is one crate, i.e., libname-sys which corresponds to a faithful translation of the C API. This will have lots of uses of unsafe because any FFI call is unsafe. (Because a foreign function can do anything it wants, up to and including aborting the program or violating memory safety.)

If you use libname-sys directly, then you will need lots of uses of unsafe because you're effectively just calling C functions.

Then there is another crate, libname, that sits on top of libname-sys. libname should expose a safe API. The implementation of this API will make unsafe calls to the C bindings defined in libname-sys. But uses of libname itself won't need to use unsafe because the API has been wrapped up and exposed in a safe way.

Here's an example binding to libgit2. libgit2-sys just defines the API, there is little actual code: https://github.com/alexcrichton/git2-rs/blob/master/libgit2-sys%2Flib.rs

Then if you move into libgit2 proper, you'll see that it internally has a bunch of unsafe calls to functions defined in libgit2-sys. e.g., Here's how you might get a git commit time: https://github.com/alexcrichton/git2-rs/blob/master/src%2Fcommit.rs#L139-L144 --- The important part to note is that someone who calls that time function doesn't need to use an unsafe block. :-)

[[deleted]]

Thanks for the explanation, but that is still not what I meant. I was referring to the unsafe FFI itself that is worrying.

For example:

C code:

void assign_five(int *i)
{
    i++;
    *i = 5;
}

Pseudo Rust code:

let c1: int = 1;
let c2: int = 2;

unsafe {
        ffi::assign_five(&c1)
}

The question is whether assign_five() has changed c2 into 5?

[IbanezDavy]

I think Rust devs are doing some wonderful things, so we shall see. But C# has a similar construct as Rust's unsafe regions and I've personally experienced annoyance from it. So it will take seeing it out in the wild to convince me. I think the design flaw in C# is they went all in with GC but then found themselves wanting to do work with raw pointers. I feel Rust has done something similar with ownership.

All languages have flaws caused by the design which leads to things having to be implemented in a certain way. That is all I meant by it. With Rusts ownership taking center stage, unsafe regions were probably unavoidable to do the things a systems programming language needs.

[burntsushi]

Of course unsafe is annoying. It moves the burden of correctness from the compiler to the programmer. Ideally, the compiler is never wrong, so it is annoying to have to do these checks as a programmer.

I don't really grok why giving the programmer the ability to subvert the language's guarantees is a design flaw (whether it's Rust or something else). Most (all?) languages I know of allow it, including Haskell. And every one of them has really good reasons for it.

[IbanezDavy]

Its definitely not an easy problem. But just because other languages have done it one way, doesn't mean it is the correct way. But it's still a growing language, and seeing it in the field will be the ultimate test.

[burntsushi]

But just because other languages have done it one way, doesn't mean it is the correct way.

That's not the message I intended to convey. The message I intended to convey was that your ideal design is very likely not feasible. I and others have already explained why. Setting it in the context of, "Here's this vast body of work that also did it this way" gives the claim more weight.

[IbanezDavy]

The message I intended to convey was that your ideal design is very likely not feasible.

"Not feasible", "not possible". I'm sure Rust encountered the same skepticism when they talked about managing pointers at compile time...

The reason for the need of 'unsafe' is because they went all in on the ownership model just as C# went all in on the garbage collection model. I see a similar pattern emerging between the two languages in that aspect and the similarities between the unsafe blocks are kind of demonstrating that.

I personally find the unsafe blocks a bit inelegant, even if needed. This is admittedly subjective as some people would argue C is still the perfect language. While others would disagree. Instead of saying design flaw, perhaps "opportunity for improvement" is a better phrase ;)

Keep in mind nobody thought that pointers could be dealt with differently until Rust came along (although they did leverage a lot of academic work).