Log in

Jan. 25th, 2017 @ 01:18 pm Rust: Intro
Tags: ,
My goal for January was to learn some rust, and if possible contribute to the rust compiler/library source on github.

Rust is a language aimed at lowish level code with the efficiency of C, but with the safety of a garbage collector and type checker. Someone (ciphergoth? fanf?) originally pointed it out to me, and obviously I'm really interested in that intersection, as my experience has mostly been in lowish level stuff, but also in avoiding all forms of boilerplate and overhead.

For a while, an informal motto was "speed, safety, convenience, pick three", which is presumably won't live up to, but shows how it's being aimed.

It's not ready to replace C or C++, it's still maturing, but has matured a fair bit. And is almost the only language anywhere where using it for things C is used for now is even conceivable.

I don't know if my interest will go anywhere, but I feel like I learned useful things from just trying. Understanding the trade-offs made in designing a language, and the types of code patterns it invites similarly to C++, and ones it recommends for and against, and thinking about what the code I write is doing in practice, seem to have made me understand programming a little bit better.

So far

I read some of the introductory books and articles. I installed the compiler and package manager (on an Ubuntu VM) and made sure I could write a "Hello world" program.

I got the source code for the compiler and libraries, tested I could build it, and looked at the open bugs. I was very pleased that there was an existing effort to tag some bugs as "easy" for new contributors. I didn't try to edit any of the actual compiler code yet, but I did submit a small change to the documentation.

And that there was a bot (rust high-five) welcoming new contributors and assigning reviewers so small patches actually get accepted or rejected, not just languish. And a bot doing continuous integreation (rust bors, with a non-rust-specific development known as homu), specifically testing patches *before* being pulled to master. So changes actually made it into nightly release almost immediately, and three months later into a regular release.

I was also pleased that the code of conduct read like it was written by someone in this century.


I've read something about some of the concepts in rust people find weird, and may try to write something about my understanding, to see how much I've grokked, and get feedback from other people who've played with rust.

I've mentioned in passing several small design choices that I enjoyed. Eg. the error handling, usually returning an Option type, which is either a success with a return value, or an error with an error type or string. Eg. putting type annotations on functions arguments, but relying on automatic variable types within function bodies. I won't review all of these, but in general, they felt good when I saw them. If I actually compare them to what I'm used to in other languages, I'll see if they still feel good.

You can also comment at http://jack.dreamwidth.org/1014231.html using OpenID. comment count unavailable comments so far.
About this Entry
Date:January 25th, 2017 04:30 pm (UTC)

My experience with Rust

(Permanent Link)
I looked at Rust a while ago and was impressed. The really new thing is the borrow checker and that's what I found most difficult. However, I can see that the borrow checker brings with it huge power in terms of spotting bugs at compile time. I'm also a fan of polymorphism, so I'm glad it has that.

IIRC, the core language supports taking mutable references to two or more different members of the same struct. That needs to be a special case because taking a mutable reference to a member of a struct temporarily invalidates the mutable reference to the struct, so you wouldn't normally be allowed to take a reference to a second member.

Arrays need a similar special case and this time it is a library feature: split_at_mut. This allows you to turn a single mutable slice into two non-overlapping mutable sub-slices. It seems to me that this could be clumsy in practice because you might not know which part of the result holds each of the bits you're interested in. For example, if you know that i!=j and you want a[i] and a[j] as mutable references, you would need separate code paths for i<j and i>j. Perhaps the language has developed more since I looked at it.

I don't think I fully got to grips with lifetimes. I remember that structs which contain references and functions which handle references need lifetime parameters. I came to the conclusion that it's best to keep all of your lifetimes distinct and give them different names to avoid confusing errors from the borrow checker. I had a program where I had tried to re-use the same lifetime for two references, reasoning that the compiler would be able to take a reference with one lifetime and produce another reference with a shorter lifetime. Somehow that didn't work.