uuid1/0 is slow because it gets the MAC address every time about elixir-uuid

[relistan]

💯 We got bitten by how much slower uuid1/0 is than uuid4/0. IME it's exceedingly, exceedingly rare for a MAC address to change on a running system unless you are using e.g. VPN tunnels. In that event, do you really want to change the way UUIDs are generated on the fly? I at least would say no.

[whatyouhide]

Also worth noting that we can probably add a poller to the elixir_uuid application that refreshes this value every 5 or 10 seconds or so. Won't add any overhead to a running system but solves this problem almost perfectly (if this is indeed a "problem").

[whatyouhide]

Ping @zyro? 🙏

[zyro]

I don't actively use this at the moment but I'm all for improving the performance here. 👍

If you open a PR I'll try to review/merge/release as soon as I can.

[zyro]

As a side note I wouldn't expect the MAC address to change while the system is running. I guess it's possible but I'm not sure I've ever had a valid case of that happening on a production system without the application restarting - nodes being cycled out of/into a cluster for a rolling hardware upgrade, for example.

I'm fine with caching the address for the lifetime of the application unless there's very low overhead and complexity to refreshing periodically.

[whatyouhide]

I don't actively use this at the moment but I'm all for improving the performance here.

We use this pretty heavily and this concerned me a bit. Are you still actively interested in maintaining it? For example, we had problems when the library was renamed from :uuid to :elixir_uuid between patch versions. Was that intentional and if so was there a reason for doing it?

[zyro]

Discussion was on #24. I didn't imagine any breaking issues since the package name was changed so anything importing the previous uuid would be fine. The core issue if I recall correctly was mixing together applications/libraries that depended on this package and uuid_erl which also defines its app name as :uuid.

I'm not spending active time maintaining this but happy to merge in patches and release new versions if needed. I largely see this as feature-complete so I would only expect bug fixes and performance improvements going forward.

I had hoped Elixir would introduce a UUID package in its standard library and make this obsolete, but that hasn't happened yet and I'm not aware of any plans for it.

[whatyouhide]

I didn't imagine any breaking issues since the package name was changed so anything importing the previous uuid would be fine.

I see.

I had hoped Elixir would introduce a UUID package in its standard library and make this obsolete, but that hasn't happened yet and I'm not aware of any plans for it.

We have no plans to introduce UUID in the standard library. This decision makes this library crucial to the ecosystem because it has the potential to become the UUID standard implementation.

I largely see this as feature-complete

I think there's still room for more features such as UUID validation, so I'm not sure I would call this feature-complete.

If you feel like this could become the standard Elixir UUID library used by the community, I'll be happy to give a hand maintaining this and moving it forward (since I have allocated OSS time to actively maintain community libraries). Let me know your thoughts :)

[zyro]

I currently have minimal time to give this library but I can continue merging pull requests and pushing up releases to hex. If you're willing to contribute time I'm happy to talk about collaborator access to the repo.

On a related note I can also see that uuid is still getting more downloads than elixir_uuid so the shift has not been very fast and I expect app name conflicts with uuid_erl are still happening - which is what the name change was originally intended to help with. Would you suggest going back to uuid as the 'official' name and release for this library? We should move this to a separate discussion if that makes more sense.

[whatyouhide]

Closing in favor of the PR (#45).