This is fantastic. Thank you. I rendered a teapot: http://imgur.com/C0kd4
And I saved a copy of your code here: https://github.com/brson/rustray ----- Original Message ----- > From: "Sebastian Sylvan" <[email protected]> > To: [email protected] > Sent: Friday, December 9, 2011 8:48:09 AM > Subject: [rust-dev] Rust experience report > Greetings, > Over the thanksgiving break I took some time to write an application > of medium complexity in Rust in order to get a better understanding of > how the language works in practice (up to this point I had never even > installed the compiler, and was merely an interested spectator of the > language's progress). > > Without further ado, here's the summary of things I ran into: > > 1. Purity, or lack thereof. > Firstly, I found the "pure" keyword went mostly unused. I tried using > it initially, but very quickly ran into places where I couldn't (e.g. > the sqrt function isn't pure, so now my vector length function can't > be either). So after an initial attempt at always defaulting to "pure" > I basically gave up and used it nowhere. That's a shame. Pure functions currently exist to support typestate (as predicates), which is not much loved right now. It's interesting that this is your number one criticism. I wonder how hard it would be to make purity more pervasive. > > Second, I'd caution about making purity the exception, rather than the > default. Purity by default is attractive. I don't know what's involved to make it happen. It would be an interesting project to go through the rust code base and see how much can be made pure. > > In general, when asking about what the default behaviour should be, I > feel like there are two criteria to consider: > a) Which is the most common case > b) Which case will cause mistakes to show up faster > > If purity worked with local mutable state, I feel that pure-by-default > would win both of these (most of my functions were certainly pure, and > using impurities in a pure function would cause an immediate compiler > error, whereas you could go months forgetting to tag functions with > "pure" without the compiler giving any indication that you're at risk > of a major "purity-cascade" if a future revision needs one of the > toplevel functions to be pure). > > 2. Mutable locals > I found it annoying that local slots were mutable by default, for a > few reasons. Firstly, it's inconsistent. Rust documentation states > that things are immutable by default, but that doesn't actually apply > to local variables. So it's inconsistent w.r.t. parameters, as well as > w.r.t. record/obj fields. Second, because mutable locals incur a > fairly high tax on readability, IME. This is again due to the fact > that you can't really rely on immutable locals to be marked up as such > (side note: I don't even know how to do this, is it possible?). Again, > witness const in C++; nobody I know bothers tagging local variables as > const. The result is that when reading a new function, you have to > spend considerable effort scanning through the code to find all the > places each variable is modified (even though most of them never are), > in order to understand the data flow. > > By the criteria above for choosing a default, immutable-by-default > wins both criteria for my code. Over 90% of my local variables were > actually immutable (though none were tagged as such). And mistakenly > forgetting to tag something as mutable would give an immediate > compiler error, whereas forgetting to tag something as immutable would > go unnoticed until someone in the far future gets annoyed by unclear > data flow and adds the right annotations in bulk (which I do on > occasion in C++, but is a rare occurence!). > > 3. Ownership of unique-ptr > I find that it's quite common to want to say "this is a pointer to a > heap box that is both uniquely owned, and will never change owner". > E.g. where you really want something conceptually close to just > storing the value "in-line", but need to put it on the heap because > you're referring to yourself recursively (e.g. a tree). Unique > pointers give you a way to say that there's only one owner at a given > time, but I'm not sure if there's a way to make sure ownership is > non-transferable. In fact, this should probably be the default (i.e. > only mutable unique pointers can lose ownership of their memory). Immutable locals would make this possible. > > Also, I had a few instance where I wanted to work with unique pointers > in a bit more flexible way than just passing them to a function, but > I didn't want to copy or take ownership of them. E.g. in kd-tree > tracing you want to traverse the two sub-spaces in different orders > depending on which is closest to the ray origin, the rest of the code > is the same so it's nice to say something like: > > let (near,far) = origin < splitter ? (node.left_tree, node.right_tree) > : (node.right_tree, node.left_tree); > > And have near and far simply be immutable references to the two > sub-trees. Unfortunately this causes a copy of the unique pointers > (resulting in an order-of-magnitude perf. hit for this application). > There may be some way using explicit types to do what I want here, but > really it seems like copying shouldn't be the default. Copying by default is becoming a problem in lots of ways, and there's a strong desire by everybody to make copying of expensive things explicit in the next round of design. Unique pointers are basically impossible to use correctly right now because they are so easy to deep copy. > > 4. I got tripped up by the mandatory literal postfixes about a million > times. This may be just a habit thing. Yep. This happens to everybody and it's frustrating. I'm scared of making the language more liberal here though because it's such a potential source of errors. Maybe there's a middle-ground. > > 5. Linear algebra looks really clunky without operator overloading. I > mean, look at this: > add(scale(n, dot(view_vec, n)*2f), view_vec) > Agreed. Rust may get some form of overloading. > 6. I seriously couldn't figure out how to use the pow function. No > amount of importing/using seemed to bring it into scope. :-/ > > > Overall, I found Rust to be quite enjoyable to work with, even though > I'm used to a higher level of tooling support (oh how I miss > intellisense). Look forward to seeing where it goes in the future! > > > Regards, > > -- > Sebastian Sylvan > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
