lazy_static has not been updated for three years. rust Is there a current alternative to it? I mainly use lazy_static to create static mutable hashmaps.
The latest issue on its repo also calls out this fact and lists alternatives, namely the same once_cell
crate @sfackler linked, as well as โ eventually (but not actually stable yet, as of this writing) โ the same kind of types as part of the standard library.
It's sad to hear lazy_static is deprecated today. I really like the lazy_static macro which was a lifesaver to a novice.
Is there anything technically wrong with the last release of lazy_static
?
It's used in 7500 crates, so deprecation will cause a lot of churn.
Would it be possible to bump the major version to 2, then deprecate 2.x.x? That should eliminate immediate large-scale churn (unless it's deemed desirable to move off lazy_static
ASAP).
Isn't the point of Rust's stability guarantees that working code will continue to work into the future? "No more updates" can be the sign of a mature, stable library, and is the end that most small crates should aspire to.
Deprecating crates simply because they haven't been updated undermines this goal, and propagates the culture of pointless churn that has become prominent in other software engineering communities. Deprecation should instead be reserved for crates that fail to address actual technical problems with their implementation.
I guess the point is that lazy_static
has a strictly
better alternative: once_cell
does everything lazy_static
does and more, without a macro, and is going to be in std soon(-ish). I view the deprecation more as a sign that new code shouldn't use it.
This is too strong of a statement for me. Nothing will go wrong if your new code chooses lazy_static
instead of once_cell
ยนโ The only tangible effect is that the source code will feel more modern, but that's a moving target by definition. Aesthetics should be left to evolve on their own through discussion and cross-pollination, not dictated from above.
ยน Assuming, of course, that your problem only needs the capabilities provided by both lazy_static
and once_cell
.
I disagree that "feeling more modern" is the only consequence. From my experience helping beginners, lazy_static
creates avoidable confusion when used. That is a reason to discourage its use or at least discourage recommending it equally.
When you use once_cell::sync::Lazy
, the type of the static is clear: Lazy<YourValueType>
. Then it is a small step to see that it must be dereferenced, just like Box
or Arc
.
lazy_static
instead hides the type โ the input syntax is just : YourValueType
. Users then get confused about why the static isn't of their type. Not only that, the macro-generated type is given a name equal to the name of the static, which produces error messages that don't make sense to people who don't have the hypothesis of macro shenanigans yet.
lazy_static
tries to communicate the existence of the wrapper by its choice of input syntax requiring the ref
keyword, which is rarely seen and not taught reliably in the age of match ergonomics, so this does not help. (It certainly didn't for me when I first saw it โ I just saw "weird thing to do something weird" not "this variable will be a pointer to the value, not the value".)