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.
4 Likes
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.
3 Likes
It's sad to hear lazy_static is deprecated today. I really like the lazy_static macro which was a lifesaver to a novice.
2 Likes
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.
6 Likes
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.
7 Likes
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.
4 Likes
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.
2 Likes
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".)
9 Likes