Watching developments in the Rust programming language is one of my hobbies. It’s one of those things I would love to see myself working in some day but right now I just don’t have the time to dedicate to it nor do I have a fitting project for it.
Compile times are brutal. For our 2400 loc it takes 20s for a dev build and 70s for a release build…Type checking occurs very early in that 20s so running
cargo buildin a loop gives reasonably fast feedback on type errors, but any time we want to add an extra print statement we pay the full price. Moving…into Rust would simplify the overall architecture but the [programmers] refuse to wait 20s…
Error messages are better than any other tool I have used. For most errors the compiler not only clearly explains the problem but also offers the correct solution. There is no secret sauce, it’s just the result of long hours from the compiler team and a culture of caring about usability.
Obviously programming today is different than it was fifty years ago or even five years ago and that’s largely due to the unthinkable speed we have access to with modern computers. I like how the Rust community has chosen to use that extra power to prioritize security and stability over features and performance.
Waiting twenty seconds to compile is a big pain when developing, but isn’t it funny how much that small delay irritates us? The Rust compiler is becoming more and more well known for how good it is at finding and describing bugs at the compile time. It’s amazing – understandable, useful, insightful compiler warnings and error! Maybe the extra nineteen seconds it takes to compile prevents a bug that would take days or weeks to track down long after it’s done its damage.
Back when I worked with the electric power grid, we were seeing all sorts of new stuff coming out with different flavors of “cool.” They had virtual RS232 over USB (what better use of USB?), kludgy GUIs, and development cycles that made bugs darn near impossible to understand and fix. Instead of using this abundant power to make sure that their device never fails and can’t be misconfigured, they used it to save on development costs or plop one more poorly-planned-out feature on the list.
There’s hardly any real risk involved with what I work on at Automattic, but we are living in a world where people can die as a result of hurried or irresponsible programming. Every modern aircraft, automobile, power grid, bank website, hospital, and pacemaker are running code that was developed with programmers pushed for making budgets and deadlines.
In summary, it’s refreshing to intentionally slow down to make sure that the stuff we do won’t break. A little more pause might end up saving lives as well as fostering the creative “incubation stage” in the minds of the programmers, making them even better yet in the code they produce.