Hacker News Reader

Comment by k__ | Hacker News Reader

Rust really seems like the next step in system programming.

Would it be possible to have this lifetimes/borrowing stuff in a scripting language?

Like, I care about who owns something, but I don't care about what something is?

Depends on the precise details, but generally speaking the nastiest problem would probably be the fact that `region analysis + type erasure = sadness`.

For instance, you can't just have all your objects be some opaque thing, you need to know if it holds borrows into other types. On one end you can certainly do runtime checking (basically everything is a RWLock) which is slow and still just crashes at runtime. Or you can maybe do whole-program analysis (slow, weird non-local errors).

As far as I can tell, Rust strikes a really clean balance for region systems. Everything about signatures needs to be declared, and the rest can be locally inferred. But when you use type erasure (runtime vtable-based dispatch) you need to decide whether the erased objects are allowed to contain borrows, and what they borrow, upfront.

Sad to read, but thank you :)

Don't scripting languages typically not exhibit the problems that Rust attempts to address?

I had the impression Rust tries to get memory safety without the need/overhead of GC.

I don't know about the borrowing system, but I believe there are several Lisps that avoid mark-sweep garbage collection. NewLisp is one such example, though I think they sidestep the issue by copying everything by default and using efficient allocation/deallocation.

Memory safety is compile-time guaranteed except in unsafe blocks.

It's a little less strong than your impression. Memory absolutely can be a problem, but instead of looking over the entire program to find it, you know the problem comes from a marked unsafe block.

Rust, among other things, prevents mutable aliasing, allows to create non-escaping pointers and provides deterministic destruction and unique ownership.

These things are essential if you don't have a GC but have a way to free memory, because the bugs they prevent would result in accessing reading or writing memory at invalid addresses.

That's not a problem with a GC, but they are still very useful because they prevent these issues that cannot be statically prevented in Java/JavaScript:

- Exceptions due to one part of the program manipulating a data structure while another is accessing it: the canonical example is someone iterating a dictionary while something else mutates it

- The program keeping a reference to mutex-protected data after unlocking the mutex

- Two threads manipulating the same object, causing races

- Something accessing a File that is closed, or in general a type in an unexpected state (this is because with a GC you can't "destroy" the previous object, but merely set it to a "closed" state that you can't statically check)

- Exceptions due to null pointers

So in general Rust is a safer language than Java, JavaScript and languages equivalent to them.

The same region/ownership discipline that Rust provides to handle memory turns out to be useful in other contexts. One is resource usage: you have to close a file handle after opening it, etc. Patterns for cleaning up after yourself are common in many languages. What Rust provides is a way to describe how long something should live and a way to enforce correct usage through compile time type checks. This can be used to ensure people using the library are unable to do the wrong thing. As a simple example, using a mutex incorrectly in safe Rust will not compile. More complex examples:

https://medium.com/@tomaka/the-glium-library-5be149d87dc1

https://blog.mozilla.org/research/2014/08/26/javascript-serv...

Not only do scripting languages generally use GC or at least refcounting, but most scripting languages (Python, Ruby, JavaScript, Lua) are either difficult to use with guaranteed thread-safety or simply do not support multithreading at all. If you don't have multithreading, you can't have data races (by definition), and it's harder to hit race conditions. It's still possible -- you can queue a callback that operates on data that's invalid -- but lots of programs will never care.

Rust is intended for performant, close-to-the-metal (hence the name) programming, so mandatory GC/RC won't cut it, but a single-threading restriction won't cut it either. And I think the way the borrow system implicitly gives you all the properties needed for thread-safety is one of the best things about Rust's design.

http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

Lifetimes are part of the type, so in that sense you would care what it is.

Seems like this would go against the nature of scripting languages.

Reply on news.ycombinator.com