Hacker News new | past | comments | ask | show | jobs | submit login

In my case, I use it because it is dead simple to get a standalone, lean, fast, native executable (on top of the other functional programming features). Cargo is a huge part of what I love about rust.



I have a great example. We have 100s of Markdown files. I needed a link checker with some additional validations. Existing tools took 10-20 minutes to run.

I cooked up a Rust validator that uses the awesome pulldown-cmark, reqwest and rayon crates. Rayon let me do the CPU bits concurrently, and reqwest with streams made it dead simple to do the 1000s of HTTP requests with a decent level of concurrency. Indicatif gave me awesome console progress bars.

And the best part, the CPU bound part runs in 90ms instead of minutes, and the HTTP requests finish in around 40 seconds, primarily limited by how fast the remote servers are over a VPN halfway around the world.

No attempt made to optimise, .clone() and .to_owned() all over the place. Not a single crash or threading bug. And it will likely work one year from now too.


Reading your comment made me realize another thing: Using rust often feels like the language is a successful attempt to take the best parts of a lot of other languages and put them together into a single, rational collection of features. Most of what's in there isn't new, but it all fits together well in one place so I don't feel like I have to make a devil's bargain for important features when I start out.


Most good languages seem to boil down to this.


Are the checks somewhat time-stable? Couldn't some of the checking (and network requests) be avoided by caching? For example by assuming that anything OK'd withing the last hour is still OK.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: