Hacker News Reader

If that was your first foray into Rust land, I hope you give it another shot. I definitly struggled with fitting into the Rust programming model at first, but a few adjustments to how I code have really helped me. Some particular points which helped me are:

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.

Sadly this is my third or fourth Rust foray. Only one was really successful - writing a tool to basically do 'git describe' using libgit2. That was a decent experience. I also tried to write a wrapper around libsoundio - got quite far but eventually gave up because of limitations in the Rust lifetime system, and because of how hard it is to do callbacks.

You need to type your Python code extremely fast to finish it 10 times faster than this Rust program:

    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");
      }
    }

It was rather more complicated than that. I could go into details but that's not really the point.

It's not the typing that is slow - it's the constant "why can't I do it like this?" stackoverflow trips. For example - how do you open a file in read-write mode? Using File::open()? Nope!

Ok that one is just poor API design - most of the time was really in restructuring to make the borrow checker happy, and fiddling with adding and removing '&' and 'ref' to get the right types.

This is a really silly counterpoint. I am not even sure what point you are trying to make. How can pasting some program show how long it would take someone to reason out how to write it?

> I wish there were a simpler language, like Rust (no garbage collector, no runtime), but that was a little more helpful and willing to do implicit things even if they are slightly slower than the most optimised code possible.

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'd estimate it took me about 10 times longer to implement in Rust than Python. And I don't exactly know Python well - it wasn't just extra time Googling how to do things.

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

Why is that the comparison point though? How long would it have taken in, say, OCaml or Haskell, which would have given similar correctness guarantees to Rust?

Because Rust is a systems language?

What does that cash out as that the programmer cares about though? A task like "read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk" doesn't need any special systems-ness (and maybe Rust is only a suitable choice for problems where you need that systems-ness, but people seem to be writing a lot of ordinary code in it and advertising it for non-systems uses).

Because C/C++ are systems languages. You can use a hammer for whatever you like, that doesn't make it the right tool for the job. If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place.

To address the heart of what you're getting at: I don't buy the fact that it took "10x" longer to read an XML file. I'll give you some amount of "longer" just by virtue of Rust's general strictness and lengthy semantics (like any systems language), but you can't just squash together your unfamiliarity with the language or its libraries and use that to determine the base line difficulty of implementation. To highlight this, consider a seasoned C# developer trying to read an XML file in python for the first time. It would probably take them "10x" longer in python too, and it won't be because the languages have different purposes/audiences or the languages' rules and conventions.

> If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place.

I'd take the view that "a little script to read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk" doesn't need any more speed than Python, but can benefit from more correctness. I'm willing to spend a bit more implementation time than Python to get more safety than Python, but I'm not willing to spend extra time just to make it faster (and frankly I'd question the priorities of someone who would). If implementing in Rust is slower than a more error-prone language, that's not necessarily a mark against it - but if I can implement faster than Rust in a language that would also have similar safety properties then I'd rather do that, even if it meant somewhat slower runtime performance.

>but if I can implement faster than Rust in a language that would also have similar safety properties then I'd rather do that, even if it meant somewhat slower runtime performance.

Why? Does this really make sense? You write it once, it runs a multitude of times. Why is the extra 30 minutes (maybe) to implement in Rust worth more than the extra CPU cycles over countless runs? It's going to be less error prone and faster.

> Why? Does this really make sense? You write it once, it runs a multitude of times. Why is the extra 30 minutes (maybe) to implement in Rust worth more than the extra CPU cycles over countless runs?

CPU cycles are cheap - my CPU is idle most of the time - and my time is expensive. Given that the script in question is fetching a file over FTP, the time taken for that is going to swamp any compute time (even in the Python implementation). Even if you could make a version that ran instantly, how many times would I have to run the script to add up to saving 30 minutes of my time? It doesn't sound like the kind of script that's going to be in use for decades.

> It's going to be less error prone and faster.

Sure, but the overwhelming majority of the time "faster" doesn't matter. So I'm much more interested in comparing languages that have the same safety properties, and whether it's possible to get the same "less error prone" effect from a language that's easier to work in than Rust.

I can't imagine a new OCaml or Haskell programmer getting this done faster than a novice Python programmer.

Personally, I don't think this is even an interesting metric. These are tools for experts, understanding expert experiences is more interesting.

Neither OCaml[1] nor Haskell[2] has performance competitive with Rust. It’s impressive how many high-level functional features Rust was able to include, but it’s ultimately a systems language—and it’s unique precisely because it’s a fast systems language that can give the sorts of high-level guarantees usually reserved for GC languages.

[1] http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... [2] https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Depends what you're competing on. IIRC (can't view your link) OCaml/Haskell performance is much closer to Rust than it is to Python (runtime tends to like x for rust, 2x-5x for OCaml/Haskell, and 70x or more for Python) - if IshKebab's starting point was "my Python script is too slow, I need something an order of magnitude faster" then OCaml/Haskell would be competitive with Rust in that space.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

stirner seems to mean something different by "competitive".

If I have a budget of 300ms and 100MB, am able to deliver it within 150ms and 30MB, why should I spend more money to make it lets say 50ms and 10MB?

There are many reasons why you might use a systems programming language [1].

> System programming requires a great degree of hardware awareness. Its goal is to achieve efficient use of available resources, either because the software itself is performance critical (AAA video games) or because even small efficiency improvements directly transform into significant monetary savings for the service provider (cloud based word processors).

[1] https://en.m.wikipedia.org/wiki/System_programming

A few languages do support such low-level controls to have such fine grain memory control outside GC hands.

So the question is, having been able to achieve half of the allowed budget, why pay for more development effort?

Of course, if the bugdet is only achievable with a lower level language, there is no way around using it.

Because sometimes there's no budget, there's "we spend less money on hardware the less resources our program uses" so faster is always better.

Because Rust and C++ have similar domains.

> Another thing I've found is that because of the type inference it often gets really confusing whether a variable is a reference or not. Doesn't help that code completion basically doesn't work at all at the moment.

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.

> A lot of it is just how restrictive the borrow checker is. Often you have to structure your code in a really weird way to satisfy it.

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.

That sounds like a good idea! Having a gateway drug helps.

For tasks like that I'm not sure why you should restrict yourself to no GC and no runtime. As Rust develops more libraries and advanced macros in those libraries you should be able to get more done quickly, but I'd think Go would be a good choice for the above task if you wanted the script to compile and deal with tons of data. Otherwise I believe Python really is the best choice here for both being very expressive and having libraries written to do most of the heavy lifting for you.

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?

Replace references with Rc's and you'll get a (slightly) slower version with no mental overhead of borrows.

> I do think the difficulty of Rust is brushed aside by its proponent.

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

I think that was more a comment on people who go "It seemed hard at first, but after a week it was totally natural and I hardly ever even think about the borrow checker anymore."

Which has not been my experience.

Neither it has been mine. I have written C and C++ only in college, so my impression might be very wrong, but I think that programmers who are proficient in low level languages are the ones that learn Rust the fastest due to the low level concepts Rust's compiler puts upfront such as sane memory management.

How much experience do you have with Rust? What about C++?

> But that doesn't explain why I can't add two `String`s together using +.

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.

> This week I wrote a little script

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.