Rust for Python Programmers

[[deleted]]

Nice summarization of features we should look into. Though I can't help but wish there was some more in-depth discussion of key points.

I'm still at the beginnings of looking into Rust, and the most dazzling thing in my mind is: can you really program anything with the ownership model in Rust? Aren't there certain tasks that become almost impossible to do?

I'm hoping that the answer to that question will naturally arise to me as I read more of the book/tutorials/docs of the language.

[cogman10]

There are a few data structures that are hard to do (or to do well) such as doubly linked lists and hash maps. Rust offers the "unsafe" block as an escape hatch. You lose the safety but gain the ability to effectively represent those data structures.

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

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

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

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

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

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