The internals of testing in Rust in 2018

Re:The internals of testing in Rust in 2018 by djrenren on Monday July 23, 2018 @04:21PM (#17595641)

Hi author here, I won't lie, it's rough. I definitely built this whole website and wrote the blog during my "compile breaks". On the bright side, typechecking is super fast so I only really have to wait when making algorithmic changes. Still, especially for anything that does code generation, you'll be tweaking the algorithm a good deal.

[ Parent | on HN ]

Re:The internals of testing in Rust in 2018 by hinkley on Monday July 23, 2018 @06:41PM (#17596620)

There's a cargo watch command that tries to do the same thing that other languages with slow compilation or test frameworks do, and that's to run all your tests the minute you save.

This narrows the time between when you have something to test and when you remember to test it. It saves you wall clock time if not CPU time.

(I highly recommend combining watch with an editor or IDE that saves all buffers at the same time, instead of one at a time).

[ Parent | on HN ]

Re:The internals of testing in Rust in 2018 by djrenren on Monday July 23, 2018 @07:15PM (#17596830)

I don't believe this would work with the rustc compiler because, although it uses Cargo to build, it has a special process that bootstraps the compiler by building itself.

[ Parent | on HN ]

Re:The internals of testing in Rust in 2018 by antpls on Tuesday July 24, 2018 @06:19AM (#17599627)

Would building the compiler on cloud instances help?

If the compiler is built in Rust, I guess it would efficiently use several dozens of cores and gigabytes of RAM

[ Parent | on HN ]