4 ms·

rust's static analysis keeps improving in new compiler version. BUT, keeps improving == keep changing. For a library like sqlite, it need to maintain compiler

rust's static analysis keeps improving in new compiler version. BUT, keeps improving == keep changing. For a library like sqlite, it need to maintain compiler compatibility. It is difficult to track a "live" language.

woodruffw 5y ago
Certainly! Lots of compiler churn means lots of downstream churn. However, for what it’s worth: I’m currently maintaining around 50k lines of Rust (both public and private code), and my experience with compiler changes has been remarkably painless: I get a couple of new warnings (usually from clippy) in the CI every few months, fix them, and move on with my life. Nothing ever fundamentally breaks: I could ignore the warnings and roll them all up into a single change every 6 months if I chose to.
- dathinab 5y ago
  I can second this. I have used rust since the 1.0 release and while there had been some churn in the earlier releases even that was fast to fix. By now it's nearly always new improved clippy analytics/warnings, but clippy is not rustc but a (the) external linker, so this isn't really rust compiler churn IMHO. Even when there was a bit of churn in the early stable releases it was often remarkable easy/fast to fix. If there where not trivial to fix things it was nearly always dependencies, not because they are bad but because if you have enough dependencies sooner or later one of them is no longer maintained or deprecates some functionality you need or do a new major release you should upgrade to. But even there it's much less painful then the experiences I had with e.g. npm and the JS ecosystem. The only really painful thing I did run into was ring/rustls during the time ring yanked all previous dependencies no mater if they where broken or worked fine and still frequently updated some of their core parts. That was no fun, but fully the fault of ring, and it's no longer doing this by now.

woodruffw 5y ago

Certainly! Lots of compiler churn means lots of downstream churn. However, for what it’s worth: I’m currently maintaining around 50k lines of Rust (both public and private code), and my experience with compiler changes has been remarkably painless: I get a couple of new warnings (usually from clippy) in the CI every few months, fix them, and move on with my life. Nothing ever fundamentally breaks: I could ignore the warnings and roll them all up into a single change every 6 months if I chose to.

dathinab 5y ago
I can second this. I have used rust since the 1.0 release and while there had been some churn in the earlier releases even that was fast to fix. By now it's nearly always new improved clippy analytics/warnings, but clippy is not rustc but a (the) external linker, so this isn't really rust compiler churn IMHO. Even when there was a bit of churn in the early stable releases it was often remarkable easy/fast to fix. If there where not trivial to fix things it was nearly always dependencies, not because they are bad but because if you have enough dependencies sooner or later one of them is no longer maintained or deprecates some functionality you need or do a new major release you should upgrade to. But even there it's much less painful then the experiences I had with e.g. npm and the JS ecosystem. The only really painful thing I did run into was ring/rustls during the time ring yanked all previous dependencies no mater if they where broken or worked fine and still frequently updated some of their core parts. That was no fun, but fully the fault of ring, and it's no longer doing this by now.