Where Rust really shines

http://manishearth.github.io/blog/2015/05/03/where-rust-really-shines/

by Manishearth • 11 years ago

150 80 11 years ago

manishearth.github.io

jeorgun• 11 years ago

Maybe I'm missing something, but why is it crucial that you hold on to a reference to the contents of the vector, and not the vector itself? Because, to me, the obvious "C++ way" to do it would be something like

    struct FieldInfo {
      //
      const std::vector<ast::Attribute>& attrs;
    }

pcwalton4• 11 years ago

Well, if the object that owns the vector is destroyed then that reference will go dangling. The compiler can't (soundly) check this.

lastontheboat• 11 years ago

That operates under the assumption that no FieldInfo will be accessible after the original vector is deallocated, and similarly requires auditing to ensure this property holds (while making no guarantees about the future).

hoodedmongoose3• 11 years ago

This is really exciting, and clearly more powerful than what you get in C/C++. That being said:

In a language like C++ there’s only once choice in this situation; that is to clone the vector.

What about a shared_ptr to the vector?

imron3• 11 years ago

Doesn't help, because you don't necessarily know when the other shared pointer could push something to vector, potentially reallocating the internal array and thereby invalidating any references you had to the contents of the vector.

hoodedmongoose3• 11 years ago

Ah okay - I didn't realize rust was guaranteeing that no one else would _modify_ the vector while an instance of that struct was around. That's pretty cool.

coherentpony• 11 years ago

Or scoped_ptr to transfer ownership.

There's certainly more than one choice, though.

imron3• 11 years ago

Not really, and I say this as a fan of C++.

These things protect against one part of the problem - deletion of the vector, but not the other part - mutation of the vector, causing a new internal allocation, and leaving references to any elements of the previous vector invalid.

It's possible to make sure this isn't happening in C++ if a) your code base is small enough and b) you are careful, but the point of the article is that with Rust, you can make the changes and be confident that the compiler will fail if you do anything dangerous.

With C++, you can make the changes and through careful checking be reasonably confident everything works (perhaps only to find out later that you were wrong). It's very different from having the compiler verify that you are not doing something unsafe.

Manishearth16• 11 years ago

I couldn't have moved the vector, it was being used elsewhere.

adwn• 11 years ago

A shared_ptr does not prevent iterator invalidation caused by reallocation, because the pointed-to vector is not locked, or in any other form stopped from being modified.

In Rust, when you have an immutable reference to a memory location, you know for certain that it won't be modified by distant code as long as you hold the reference. This guarantee also allows more compiler optimizations, because v[5] has the same value after a function call as before.

hoodedmongoose3• 11 years ago

Thanks for the explanation, I missed that!

Manishearth16• 11 years ago

Remember that this was an API, exposing the `&[Attributes]` to external consumers. I may not want to hold pointers to the insides, but a consumer of the API might.

Also, iterator invalidation.

Also, runtime overhead of shared_ptr.

(I added a footnote to the post to explain the issues with shared pointers)

shafiee01• 11 years ago

This is really useful; I have been recently working on a huge c++ project and I had the exact same problem you mentioned with large vectors. The way I handled this problem was to wrap vector in a class which provides locking mechanism for expanding operations so while the vector is growing nobody can access it. I am excited to try Rust soon.

berkut3• 11 years ago

And this is despite the fact that I still don’t know where that particular vector is modified or destroyed — I didn’t explore that far because I didn’t need to! (or want to :P)

I find that a bit worrying - while it might well be an example of what's technically possible in some cases of using Rust to prevent segfault-type crashes, it doesn't mean there aren't now logic errors in the code which would do something just as bad. I guess it depends on how well you know the code and the context in which it's being used.

tatterdemalion6• 11 years ago

it doesn't mean there aren't now logic errors in the code which would do something just as bad

Yes, it does. He wants to have immutable access to some data, the Rust borrow checker's rules provide certainty that the data is not deleted or mutated while his code is accessing it.

What could happen that is "just as bad"? Data being referenced cannot be changed.

tatterdemalion6• 11 years ago

I think an important thing to make sense of this is that Rust doesn't guarantee that what Manishearth did will work! Just that if it doesn't work, the code will not compile. It could have been the case that this vector was mutated or deleted at some point during the lifetime of his new struct; in that case, his code would not have compiled.

berkut3• 11 years ago

In this case it does.

I was more talking about the overall not caring theme. I'd hope that's only because they know the code so can make those sort of assumptions.

Are you saying Rust can find and prevent at compile time logic errors as well?

frankmcsherry• 11 years ago

Would you find it equally worrying if stack-based languages claimed they improved over x86 because you needn't worry about clobbering values in registers? I guess it depends on how well you know the code and its context. Might still be logic bugs.

And man, functional languages. It's pretty much 100% logic bugs there. I worry most about those sort of programs.

chousuke• 11 years ago

If you only have 100% logic bugs in your code, I'd say the code is in damn good shape. That means all your bugs are "meaningful".

Different programming platforms have different "incidental complexity" causing bugs not related to actual program logic, but merely how it is put together, so to speak. In particular, Rust seems objectively better than C++ in this regard.

Manishearth16• 11 years ago

What sort of logic errors would be possible? The slice cannot be mutated, and the compiler has verified for me that nobody else is mutating it.

I was just holding on to a reference for an API to consume.

Of course, in more complicated situations you need to worry about logic errors. But in this case I was pretty sure I didn't have anything to worry about.

Still you never have to worry about memory unsafety, which is a huge cognitive load off my mind. Similar to how you don't have to worry about some types of memory unsafety in languages like Java. Or how most programmers don't worry about cache coherence since the processor handles it. Rust just raises the bar. If you know what it can and can't prevent, you can be carefree about many things.

picardo4• 11 years ago

For an outsider, Rust is still barely usable. I tried building a simple demo using the beta release today, and regretted right away. Lots of "unstable feature" errors that I can't figure out how to get rid of. Many useful features are unstable. I don't think I'm going to touch it again for a few months.

tatterdemalion6• 11 years ago

What was unstable that you wanted to use? (Not trying to deny your experience: reporting this helps the Rust team determine what to prioritize)

picardo4• 11 years ago

Collections. I tried to set the flag to allow them. This used to work in the dev release I downloaded 2 months ago, but there is a new error that says unstable features are not allowed in the beta release and I cannot override an outer flag –– or something like that. At that point, I just gave up.

rdtsc• 11 years ago

Sorry you had a bad experience. Just curious, have you tried asking for help on /r/rust or irc? I find Rust community is pretty friendly and helpful.

sjolsen• 11 years ago

I tried using Rust the other day, and I had the same problem. What I found indicated that "unstable" features are permanently disabled in all but the nightly releases.

picardo4• 11 years ago

Ah, gotcha. Well, that was not clear to me.

SamReidHughes7• 11 years ago

The article says you have to clone the vector, as if it's not completely normal to have one object hold a reference to another, "unsafely," in C++, without the world coming to an end. Having one object contain a reference or pointer to another in C++ is completely normal and something you certainly would "dream" of doing -- it happens all the time, you can find it everywhere in the STL, so I don't know what the blog author is getting at. Looking at the diff, the type SubstructureFields already has the lifetime parameter on it, and making FieldInfo, which is only used as a field in the SubstructureFields type (which owns its FieldInfo objects), be subject to the same lifetime constraint, is something that would be perfectly ordinary C++ and it registers near the bottom of the use-after-free risk scale.

pcwalton4• 11 years ago

Looking at the diff, the type SubstructureFields already has the lifetime parameter on it, and making FieldInfo, which is only used as a field in the SubstructureFields type (which owns its FieldInfo objects), be subject to the same lifetime constraint, is something that would be perfectly ordinary C++ and it registers near the bottom of the use-after-free risk scale.

Which is why it works. But isn't it nice when the compiler is aware of the "use-after-free risk scale" for your data structures?

SamReidHughes7• 11 years ago

I prefer technical accuracy in technical blog posts. If you want somebody to preach at about the merits of compiler-checked safety, it's not me.

Manishearth16• 11 years ago

Oh, the general situation is something that might be common in C++, but in this specific situation -- the vector was created and held (and most probably being mutated) somewhere far away, and I have no clue what is being done with it -- and the relevant portion of the codebase is huge -- holding a reference is something I wouldn't dream of doing.

SubstructureFields could have had a lifetime parameter of something that was supposed to live longer, we can't be easily sure.

SamReidHughes7• 11 years ago

You can wrap the vector parameter or pointer/size parameter in a type, chase the compilation errors up to the places where the original vector exists, and make sure the usages there be well-protected.

thrownaway24242• 11 years ago

A C++ function returning pointer to vector, or a public field of that type, would be considered bad API for the reasons mentioned in this article. The solution is to not do that. I'm not sure that Rust's ability to allow shared ownership of a vector makes this API pattern any better.

Rusky• 11 years ago

What's wrong with that API pattern if the compiler guarantees that it will be used correctly? It's certainly simpler and allows for better code reuse.

lobster_johnson2• 11 years ago

But it's a bad pattern in other languages because they don't guarantee safe access. Rust does, thus making it a good pattern.

It's like saying that driving your car off a cliff is always a bad idea even when you've acquired a car that can fly.

thrownaway24242• 11 years ago

It's a bad pattern in any language because it exposes too much details of storage layout and violates encapsulation. You probably don't want to expose internal implementation details in your API unless such exposure is critical to performance, and if it is critical to performance it seems unlikely that you'd be writing it in anything other than C++ anyway.

Matthias2473• 11 years ago

I would assume it would be bad API design in Rust too.

For all use-cases that are possible this kind of API it would be safe to use a const reference to a vector it C++ too. Of course with the difference that in Rust the correct use can be statically verified.

But I think for a really flexible API that allows parallel modification you should go for a copy or some kind of immutable-vector oder copy-on-writer-vector type in both languages.

Manishearth16• 11 years ago

Why would it be bad API design in Rust? Rust ensures that it's safe.

(Besides, all these were internal functions that wouldn't be used as an API)

You don't always want parallel modification.

vbit• 11 years ago

Garbage collected languages handle this fine too.

jwilm• 11 years ago

They handle it fine by tracking references at runtime. The advantage here is compile time verification that the reference will stay valid for the life of the struct - zero runtime overhead.

Manishearth16• 11 years ago

Iterator invalidation is still a problem.

Plus, having a GC for this would be quite heavy. The codebase was a compiler -- performance is necessary since a compiler's going to be slow anyway.

steveklabnik2• 11 years ago

But only for memory, and not for other kinds of resources.

hckr1292• 11 years ago

I've been following Rust for a long time now, and I'm very excited about the possibilities. However, I don't have a CS degree, and my work as a full stack web developer has only put me in contact with garbage collected languages: NodeJS, PHP, and a little Python.

I just spent an entire week working on a chatbot in Rust, and I found the steep learning curve to be very challenging. While Rust seems to be a big win for teams that are accustomed to C++/C development, it does seem to be very demanding for web devs who always work with a garbage collector.

In particular, I was trying to use Iron to write an http server that could receive web hooks. Iron, quite sensibly, handles each incoming request to a server in a separate thread. However, as a beginner it's very challenging to figure out how to persist data between requests without writing to disk or persisting to a db. Mutating state across threads is hard. Currently, there's also no version of channels that are single producer, multiple consumer. I'm sure as the ecosystem develops, more examples will make this easier, but for now it's surprisingly difficult to figure out.

Fortunatey, the #rust IRC channel supported me all the way. It's a very friendly and active community, but without their support I would have probably given up.

I look forward to seeing more posts at this level of detail help those of us struggling to learn Rust understand how the experts use Rust.

Manishearth16• 11 years ago

I'm considering writing a GC for Rust next. It won't be as easy to use as the other GCs, but you will be able to put the ownership of stuff in the hands of the GC if you wish.

Yeah, a lot of people are excited about Rust for webdev, but there is a steep learning curve and it's quite different from the languages most are used to. For webdev I personally think Go will make it, it feels a lot like Python/Ruby when programming, even though it's compiled and probably faster.

Daishiman• 11 years ago

I don't really think that's a problem with Rust so much as inexperience with languages that have no garbage collection. If anything, the problems you had would probably be exacerbated by languages like C and C++, which in many ways are deceptively simple, yet there are tricks to be aware of in every turn. Doing memory management is hard because of the nature of the problem.

steveklabnik2• 11 years ago

I care a lot about figuring out how to teach people like you to use Rust. I've primarily worked in Ruby for the past several years, but I did have that degree, and C was my second language. So it's a bit harder for me, as I had my 'aha' moment with a lot of this stuff quite a while back.

I'm hoping as time goes on to include more stuff in the docs that's about generic systems stuff, rather than 100% Rust specific, exactly for this reason. The stack & heap chapter of the book (which is upcoming) is part of that. But, I gotta finish off the Rust-specific stuff first...

I agree with wycats: Rust is going to bring systems programming to a lot of people who haven't done systems programming before, just like Node brought a whole new group of people to server-side code. It's our job to give you the support you need to be successful at it.

joslin01• 11 years ago

So I'm not sure I fully understand why you would target Rust as a web development language in the first place except pure curiosity of working in the language, but it appears there's more to the story. You're excited about Rust's possibilities -- in web development or just in general? And you gripe it's "demanding for web devs who work with a garbage collector." This makes me pause and think, why are we talking about web devs in the first place? From what I understood, Rust is a systems language and by systems language, it means stuff a lot lower level than `route '/me' => controller.toMe!`

Thing is about web dev is that (1) it's a get-things-done playing field and (2) primarily just data delivery. The idea that you would want a language that doesn't have garbage collection is just silly. Why? What complex operations are you doing in each request/response cycle that demands this sort of computational horsepower? And if you are doing said complex operations, maybe you should rethink how you're delivering that data and creating it? GitHub is huge and runs on Ruby. Surely, you can't be wanting to use Rust to improve your performance are you?

Mutating state across threads is hard

Yep, so maybe you should target a language / framework that abstracts this away from you? I wouldn't say anything usually but you say it's "surprisingly difficult to figure out." Come on really.. programming languages are not created just for web devs...

I don't know. If you're trying to be productive AND change your toolset, it sounds like you just want a typed language. I wouldn't put bet too much of your time-and-focus-chips on Rust becoming a language for web developers. Do you see many people using C++ to write their servers? Nope. And don't take my message the wrong way. It really just bewilders me because I see a comment like "Yea I want to help people like you!" and I'm like Huh??

Manishearth16• 11 years ago

FWIW Rust is intended to be more than a systems language, but is designed as a systems language first (but other use cases are all taken into consideration)

gbersac• 11 years ago

I agree, the #rust IRC channel is very helpful, with a lot of people nice enough to help you. It should be considered a feature of the language : having a helpful community.

barosl• 11 years ago

While I like the overall Rust community, I'm a bit skeptical to this, because all the language communities I've seen claim to be friendly and helpful.

There may be some difference in degree, though.

alkonaut2• 11 years ago

As a novice I find that when the compiler starts telling me do to things it will go one of two ways: either what the compiler tells me to add will quickly propagate until it's happy OR it will propagate until lifetime arguments have spread through the entire codebase, turning everything into token salad. The hard part is having a mental model of the data so you can reason about lifetimes. The compiler may help you to get it formally correct, but what would be really cool would be if it would help you find the "inversions" or "isolations" that you will need in order to not end up with lifetime soup.

Manishearth16• 11 years ago

Yum, salad. In my experience this happens when you overspecify a lifetime or something. After I got this code working, I messed with the lifetimes a bit -- I added one extra `'a` tying the lifetimes of something else to existing bound references. That propagated like wildfire and finally became unusable (proving that those two references could not/would not have the same lifetime).

In more complex situations, it's generally worth thinking which lifetime should be bound together for the first few functions and structs. After that point just trust the compiler.

It's not too hard to get a mental model of lifetimes, really, and once you have it you can look at lifetime parameters and figure out what they mean and how they work with each other. You're anyway implicitly thinking of them as scopes. I usually just ignore lifetime parameters -- they're something you learn to gloss over whilst reading Rust code, and I only really read them (and try to understand them) when I have lifetime errors. Sometimes the lifetime error is due to something unfixable, in which case the compiler will often lead me through a wild goose chase saladifying the entire codebase, or the lifetime error is fixable, in which case the compiler's suggestions usually work. Sometimes they don't, but in those situations you can still fix it by trying to understand the why of it (like how I did in this post, though in the case of this post the entire "understand the why of it" was an afterthought) because things worked.

alkonaut2• 11 years ago

I bet there are a few common "patterns" to rust ownership, and equally many pitfalls and rookie mistakes when one fails to pick one of these patterns. It becomes extra hard if you approach Rust from a Java/Python/C# perspective where the slightest bit of allocation/RAII and mostly even thinking of the stack feels completely alien. You have to learn that and Rust.

I'd love to see a kind of rust ownership tutorial in which you are asked to address a simple CS problem where these patterns occur in Rust. For example, many seem to find it hard to write a factory type. The next problem could be a doubly linked list and so on.

shin_lao• 11 years ago

Actually having a constant reference as a member works as expected in C++ because the compiler will force you to initialize it a construction.

It is true it will not check at compilation that you access a const reference of a destroyed object, but to be honest with RAII this is not really a problem as the lifetime of your objects should be pretty clear, by construction.

In debug mode your program will quickly assert if you access a destroyed STL container.

To be honest I think in this case:

- either you want to snapshot the value and therefore you should clone the container (almost no performance cost for small containers)

- you want to access the current value but then it means you know about the lifetime.

al2o3cr• 11 years ago

"the lifetime of your objects should be pretty clear, by construction"

Given the potentially-unbounded consequences of triggering UB in C++, "pretty clear" seems like not enough.

ExpiredLink• 11 years ago

People don't choose a language. They choose a platform (or stack or environment). If you want to evaluate a language look at the language's platform. Currently Rust is not part of any platform but may become the language of the 'Mozilla platform' in the future.

Manishearth16• 11 years ago

I don't think Mozilla plans to create a Rust-based platform, but the community is already making libraries that are useful at various levels of a stack.

grayrest• 11 years ago

There's no overhead in caling a C api nor in other code calling Rust code as if it were a C api. There's FFI setup and some caveats both ways but a lot of the larger Rust projects involve (e.g Servo, Piston) interfacing with pre-existing C libraries.

madez• 11 years ago

People choose standards, not platforms. Some use just platform-specific standards, others use cross-platform standards. Rust doesn't need a platform, it needs support for cross-platform standards.

This platform advocacy comes from what business needs (ability to extort money by gatekeeping), not what's technically sensible nor useful for the people.

Where Rust really shines

Related Stories