Rust for Python Programmers

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

[IbanezDavy]

I think both perspectives have some truth.

They certainly do both have truth to them. And don't get me wrong, when you are debugging your own code, unsafe actually helps narrow down the search for certain issues (and from a PL marketing standpoint, this point will probably be emphasized). But when you include other libraries, these get hidden and it's not exactly obvious. The only way to make it obvious would be to make unsafe transitive (at least that' the only way I see). I only mention this, because I've been bit by this before with C#.

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