The new Time::Instant in 1.19 is great. I mainly used Time.monotonic to measure how long some operation took and Time::Instant#elapsed is perfect for that.
What isn’t great is the long list of deprecation warnings when running specs in some of my shards. Updating apps is fine because we control which version of Crystal they use. That’s not true of shards, though. Updating those shards to use Time.instant may not be feasible if someone’s still using it on Crystal 1.18 or earlier.
I ended up making a small module that provides a unified interface based on the Crystal version at compile time. Nothing fancy but it does the job lulz!
It’s a bit annoying that it went from not existing to making the alternative deprecated in a single release. So now we have to choose between saying “this only works in crystal >1.19” or getting a ton of deprecation notices for code that works fine.
I believe the annotation reporting may be a bit too noisy.
The intention of these annotations is primarily to avoid using deprecated features in new code (unless it needs to be compatible with older versions), and maybe start to migrate old code. But a deprecation notice is not intended as an immediate call to action that you need to replace it at once.
You can also entirely ignore warnings for library code (--exclude-warnings=./lib).
I like how Elixir deals with deprecation in its stdlib:
soft deprecation in version X:
warning in docs
no compilation warning
hard deprecation in version X+n:
removed from docs
compilation warning
It gives some time to adapt software without being annoyed.
For example libraries can wait for the hard deprecation and not care about backward compatibility with Elixir < X yet still be compatible with the latest n releases.
The way this happened might’ve been more palatable for methods with fewer dependents than Time.monotonic, to be clear. That method being such a lynchpin for measuring how long something takes in places that Time.measure might not be suitable due to block semantics made it a bit of a perfect storm for a wall of deprecation warnings.
Also, periodic reminder that the @[Deprecation] annotation is honestly amazing. The ability to show deprecation warnings at build time and in docs with a single line of code is amazing. I tried to do something similar in Ruby 15-ish years ago and it was a gross hack.