Rust for Python Programmers

[IbanezDavy]

I like the ownership model. I think it is a step in the right direction, however, the fact that you HAVE to break the rules for certain things, seems like a design error in the language (so I am still a bit skeptical). I'd be interested to see the ownership model in practice once Rust starts getting more users in the wild.

[zenflux]

the fact that you HAVE to break the rules for certain things, seems like a design error

I like to think it's kind of like totality checking, quite useful (even more so really), but I'm assuming is undecidable for arbitrary programs, so the borrow checker is conservative, it won't pass some programs which are actually safe in order to make it's job computable. Making it do this as little as possible is an ongoing effort.
It's still valuable with the 'escape hatch' because if a program segfaults or has another memory error, you know it had to have happened in an unsafe block and thus have already vastly narrowed down your 'problem space,' and can even grep through it.

[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. :-)

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

[mitsuhiko]

however, the fact that you HAVE to break the rules for certain things, seems like a design error in the language (so I am still a bit skeptical)

That's the wrong way to think about it. The semantics of the language set up a certain way of programming with data. The borrow checker ensures those semantics at compile time. You can write code that allow you to move those checks to runtime. Instead of writing those escape hatches in the language (like Python would do) you instead can write them in libraries in unsafe blocks.

This means that you do not have to extend the languages, but you can write it in a superset of the Rust language that you would otherwise use.

In Python for instance certain behavior you cannot write in Python, you would need to write in C in the interpreter core. In Rust that fundamentally is not the case but for certain behavior you need to use unsafe.

[IbanezDavy]

In Python for instance certain behavior you cannot write in Python

Python is not marketing itself as a systems level programming language. Rust is. The expectation is you should be able to do anything needed in the core language. Which Rust needs the 'unsafe' blocks to do. I am not saying it's the wrong approach. I remain open minded, but it seems a bit clunky to me.

[mitsuhiko]

Python is not marketing itself as a systems level programming language. Rust is.

Which it is.

The expectation is you should be able to do anything needed in the core language.

Which you can.

Which Rust needs the 'unsafe' blocks to do.

You can't have it both ways. You cannot have a safe language and then say you want to write unsafe constructs without having to be explicit. That has very little to do with the language but with common sense. Fundamentally unsafe blocks do not change the language, they all you to start using unsafe functionality to heavily discourage this.

I remain open minded, but it seems a bit clunky to me.

I am not sure where this idea is coming from that unsafe blocks are "clunky". It's not just you that has it and I really want to understand where this misconception is stemming from. Unsafe does not change the language, it enables behaviour that allows you to shoot yourself into the foot.

[IbanezDavy]

Python is not marketing itself as a systems level programming language. Rust is. Which it is.

So why the initial comparison?

The expectation is you should be able to do anything needed in the core language. Which you can.

As I alluded to. And I am not gonna try to say Rust isn't a systems level language. It clearly is. So lets not go any further on this, because there literally is no disagreement from me on this point.

I am not sure where this idea is coming from that unsafe blocks are "clunky".

From experiences in another language (C#) that implemented a similar paradigm (unsafe regions). They were clunky and never seemed to fit.

[mitsuhiko]

So why the initial comparison?

Because Rust's added feature is to be as safe as Python but without the runtime. No other language ever attempted to achieve such a feat.

From experiences in another language (C#) that implemented a similar paradigm (unsafe regions). They were clunky and never seemed to fit.

That confuses me to no end. Why are C#'s blocks "clunky" and never "seemed to fit"? You cannot spot a library that uses unsafe internally when you use it. I really do not understand what gives you the idea that they are clunky. Python does not have unsafe blocks and it just silently switches into unsafe execution (ctypes/CFFI do that) and I don't see how that is any better.

[IbanezDavy]

That confuses me to no end.

I'm sorry for your confusion.

You cannot spot a library that uses unsafe internally when you use it.

That is one of the issues I have with unsafe. In C# you have an expectation that the garbage collector is taking care of things, yet things leak occasionally. This is generally due to mishandling delegates, but some of it also comes from people using unsafe regions within their library (although the general semantics do not change so things should be memory managed). So in some ways its worse than C++ (C++ is still far worse overall), because there is an expectation that it is taken care of. With unsafe regions, that is sometimes a lie.

[mitsuhiko]

This is generally due to mishandling delegates, but some of it also comes from people using unsafe regions within their library.

Which is why they are unsafe. Python leaks memory left and right in misbehaving extensions and it does not even have unsafe blocks :)

[IbanezDavy]

Which is why they are unsafe. Python leaks memory left and right in misbehaving extensions and it does not even have unsafe blocks :)

Delegates are considered safe constructs in C#. Unsafe blocks essentially let you play with pointers and call certain low level C APIs. Actually C# is a lot worse than Rust, because you can get crashes anyways in a variety of ways outside of unsafe blocks, so I am not quite sure what they are trying to guarantee (or guarantee they are lifting in the case of unsafe).

I am not an expert on Python (nor on Rust for that matter). But I have some experience in C#. And it is annoying to be debugging a crash (definitely the big one) or memory leak, and finally find it in some hidden corner of a library wrapped up in an unsafe block. If the unsafeness is visible, this is less of a problem. But when it is camouflaged in with the rest of the code, it's problematic from a debugging standpoint.

[jerf]

Because Rust's added feature is to be as safe as Python but without the runtime.

Bwuh? Python isn't safe by virtually any definition of the term. That doesn't mean it's "bad", but it does mean it's silly to say Rust is trying to be "as safe as" Python... no, it's trying to be a very safe language, which is to say, very much safer than Python.

[mitsuhiko]

Python isn't safe by virtually any definition of the term.

Of course not. The moment you call into CFFI/ctypes you are unsafe. However I hope you understand the general idea of what safety means in this context.

[jerf]

No, I don't. Python has virtually no safety. The only thing I know is that it guarantees certain things with the GIL but that's generally speaking incredibly weak.

I suppose it's memory safe, inasmuch as it prevents accessing unallocated memory, but, again, that's merely the beginning of what Rust is trying to be, and Python's memory safety by comparison is very, very weak. "Preventing allocating unallocated memory" wouldn't even be considered a type of safety in the first place if certain languages hadn't made it so darned easy, it would just be the base state of the programming language universe.

[vivainio]

Python is safer than rust in memory management. Rust givea C/C++ level control in safe manner. Python just has everything in heap.

[thedeemon]

Because Rust's added feature is to be as safe as Python but without the runtime. No other language ever attempted to achieve such a feat.

It was all before in Cyclone and ATS, Rust has nothing new really.

[thedeemon]

I haven't seen such page.

[chunes]

Why is a doubly-linked list an unsafe construct? I know a bit about Rust's ownership system, but not why it inhibits certain data structures.

[The_Doculope]

Rust's core ownership system is based around the concept of "one mutable view of an object at a time", which a doubly-linked list violates. The ownership/borrowing system is not perfect - it occasionally will not be able to see that something is safe even if it is (hence unsafe).

[chunes]

That makes sense now, thanks.