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
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
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
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
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
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".)