Remove lazy_static

[vbasky]

• Latest iteration of Rust since 1.71 can perform LazyLock which is what lazy_static was used for
• Use standard library instead of another crate

[akprasad]

This is really exciting! thanks for taking the initiative to do this.

There are three things I want to check before merge:

• the code doesn't build for me on Rust 1.74 because LazyLock is not stable on that version. I think it was stabilized only in 1.80. So first we should upgrade the package version to 1.80 and see if that breaks anything.

• Relatedly, I want to understand if there's some downside to using a newer Rust version generally. I don't understand this very well.

• I've heard rumblings that LazyLock might have problems with no_std but lazy_static does not -- not sure if there's any truth to that, but it could potentially affect our Wasm bindings (can't recally if they need no_std or not).

[akprasad]

I don't know what the usual style is, but I like having two blank spaces before heading so that sections are clear. Can you revert the changes to this file?

[vbasky]

This is the VSCode Extension that I use for Markdown Lint. The extension has well written rules that a markdown should validate against. The cleanup that I did was based on the extension's recommendation

This is how it offers suggestions to make markdown compliant. But you are right. The change here is unrelated to what this PR is inteded for. I should revert this change, will do.

[akprasad]

I've done some reading on the second point (downside of upgrading rust version). The key phrase is MSRV, "minimum supported Rust version." Useful discussion for context and thinking through options: rust-lang/libs-team#72

The idea is that our MSRV is bounded below by all of our dependencies, and whatever version we choose, that will be the MSRV for any project that depends on Vidyut. So if we need to use 1.80 to support LazyLock, any project that depends on Vidyut also needs to use 1.80 at minimum.

I've checked a variety of libraries that we depend on, and they tend to be at most around version 1.63.

So my current inclination is that the cost of upgrading the MSRV outweighs the benefit of moving off of lazy_static, but I need more research to be sure. To change my mind on this, I would want to see:

• examples of popular Rust libraries with high MSRVs, ideally a library we depend on currently.
• some solution that lets older versions of Rust work with newer MSRVs
• a way to use LazyLock in versions before 1.80

[akprasad]

Actually, can we use use OnceCell? This was stabilized in 1.70 and we use RefCell already, so this might solve the problem without needing LazyLock.

[vbasky]

Modified LazyLock with OnceLock because of MSRV compatibility to 1.70

[akprasad]

Almost there!

Can you revert all changes to ARCHITECTURE.md ? I see there's still a stray line there.

I tried editing it directly to avoid some back-and-forth but wasn't able to. I can fix up future PRs if you enable this, I think: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork.

[vbasky]

Fixed the stray commit and squashed the commit.