Reflections on Rust, and the Sand Castle Metaphor

EDIT: Curious why people are downvoting this. Is it really so taboo to suggest that Go could be nearly as pleasant as Rust at something? Do I really need to roll out my Rust fanboy creds every time I participate in a thread on the language?

And of course Smalltalk images can be saved on one platform and restarted on another, but that's with a VM.

> This is especially true when it comes to the more complicated ones like moves and futures, but also true for simpler ones like borrows. What I didn’t know when I wrote about it in frustration a month ago is that it doesn’t take a little longer longer to be effective in Rust compared to other languages, it takes 10 to 20 times longer.

I think futures might be exacerbating the authors problems. There was a recent post [0] that does a good job explaining why futures are so hard and how the in-progress async/await features fix it.

[0] https://aturon.github.io/2018/04/24/async-borrowing/

let buf = [0u8; 810241024];

For instance C's equivalent of Rust's enum would be tagged unions, however the compiler cannot enforce the semantics of tagged unions and will gladly let you access random members regardless of the tag.

Same story with the borrow checker compared to C's "whatever you say chief" approach to resource management.

Rust is definitely not the only one to offer these guarantees and some languages even go further (such as Idris for instance). The reason Rust stands out is that it can be used basically anywhere you'd use C or C++, something few other languages can claim.

The borrow checker is the primary reason I feel this way. A smaller aspect is how easy it is to write white box unit tests. I can have an equivalent of a C++ static function in Rust and run unit tests on it. For C++, I'd either have to hack up the source files for when building my unit tests or make turn the function from static to being exposed in a header so my tests can access it.

Having a GC doesn't preclude you from leaking resources(file handles, textures, etc) and you're at the mercy of whenever the finalizer decides to run once the GC has determined it's time to free an object. Usually this manifests as your Java application humming along until you hit some GC threshold cliff and then perf/memory plummets.

I also can't enforce ownership in Java which drives me up the wall. Once you hand out a ref anything is fair game and calling code is free to add that ref to the root GC set so that it never gets freed.

In addition the explicit error handling (together with enum error types) allow the compiler to check that you have handled every error case.

Rust has enabled me to write programs that just don't contain bugs (after an initial testing period). This is certainly acheivable with other languages, but it involves a lot of discipline, writing tests, etc. Rust makes it easy.

That doesn't surprise me at all. Writing it in C++ would probably take me a lot longer than writing it in Python too.

Out of interest what setup are you using? My editor is telling me whether a variable is a reference or not so maybe this is just a plugin you don’t have? I’m currently using Rust Enhanced (with RLS), I believe VSCode shows you this information too.

Which kind of makes me wonder if a language like the one you wished for existed would it not be better to pick one of the existing languages instead and maybe use type annotations to help in Node or Python?

I think a lot of proponents might argue that Python is better than Rust for very, very small scripts like this, but as your program grows, Rust pays its dividends quickly. This hasn't been my experience with Rust in my 4 years with it; it makes certain classes of errors harder, but I've not yet gotten to the point where the compiler is actually saving me time--the time I spend pacifying rustc is more than enough to write it in Go (or even Python) and get my extra confidence from tests. I like the idea of Rust, but it's hard for me to justify it for the applications I tend to write.

Then how do you explain the constant push for "more ergonomics"?

1. It really helped me to stop trying to force my code to be as pretty as possible the first time around.

2. If you are getting errors about a lifetime not living long enough in a complex expression, it can help to pull some part of it out into a helper let binding.

3. Adding an artificial scope (a curly block in the middle of another block) can be a great way to control the lifetime of a borrow.

4. clone() all the things! This is a major advantage that Rust has over other ball-and-chain languages like Haskell. When you get into a type-tetris situation in Haskell, you just have to find a way out. In Rust you can often just clone() something that you would rather not have to clone() and move on. I love being able to tell the borrow checker to go away while I concentrate on my program logic. Later I can always go back and fix it.

The fiddling with borrows isn't about being as optimised as possible, it's about being correct in the absence of garbage collection. Are you sure you need no GC and no runtime? Tasks like the script you describe sound like a perfect fit for something like OCaml.

I've rarely found this the case for me but I came from C++ and am generally used to thinking in terms of lifetimes. Could you elaborate on how you ran into problems with borrows messing up code structure?

> Dealing with strings is another pain point. I get why there is `&str` and `String`. But that doesn't explain why I can't add two `String`s together using +.

I feel like the Rust stdlib takes after C++ in making costs obvious to people and not providing shortcuts for slow operations, causing the ergonomics to scale with performance.

Something that some of us in the CLI-WG have been talking about is creating a library that interops with the standard library but instead focuses on python-like semantics at the cost of performance. This will be a big benefit for "quick scripts" and people learning the language while allowing people to still fall back to high performance idioms as determined by a profiler.

Unfortunately, this is a little lower on our priority list for now.

Because that would consume both Strings, which doesn't make sense. The impl that exists only consumes the left string, reusing its buffer.

This seems like an odd thing to complain about since if you try it the compiler will tell you exactly what you should do instead.

    extern crate xpath_reader;
    extern crate regex;
    
    use std::io::prelude::*;
    use std::fs::File;
    
    use xpath_reader::Reader;
    use regex::Regex;
    
    fn main() {
      let mut contents = String::new();
      File::open("test.xml").expect("Unable to open the file").read_to_string(&mut contents).expect("Unable to read the file");
      //println!("File contents: {}", contents);
    
      let reader = Reader::from_str(&contents, None).expect("Cannot parse XML file");
      let files: Vec<String> = reader.read("//file").expect("Cannot find file entries in XML file");
      //println!("Files: {:?}", files);
    
      for file in files.iter() {
        println!("File: {}", file);
        let mut contents = String::new();
        File::open(file).expect("Unable to open the file").read_to_string(&mut contents).expect("Unable to read the file");
        //println!("File contents: {}", contents);
    
        let re = Regex::new(r"foo bar").expect("Cannot compile regex");
        let replaced = re.replace_all(&contents, "baz").to_string();
        //println!("File contents: {}", replaced);
    
        File::create(file).expect("Unable to overwrite the file").write(replaced.as_bytes()).expect("Unable to write to file");
      }
    }