7 ms·

Odd to me that the focus seems to be on the inactivity of Google's package when https://github.com/gofrs/uuid https://github.com/gofrs/uuid not only conforms to

by kayson 7mo ago

Odd to me that the focus seems to be on the inactivity of Google's package when https://github.com/gofrs/uuid https://github.com/gofrs/uuid not only conforms to the newer standard but is actively maintained.

da_chicken 7mo ago
While the uuid package is actively maintained, it hasn't had a release since 2024. Indeed, there's an open issue from June 2025 asking about it: https://github.com/google/uuid/issues/194 https://github.com/google/uuid/issues/194
- rafram 7mo ago
  The RFC isn’t changing, is it?
  - JimDabell 7mo ago
    I’m not sure of the state of that particular library, but yes, the RFC has changed significantly. For instance, the UUIDv7 format changed from the earlier draft RFC resulting in incompatibilities. This is an example of an unmaintained UUID library in a similar situation that is currently causing incompatibilities because they implemented the draft spec. and didn’t update when the RFC changed: https://github.com/stevesimmons/uuid7/issues/1 https://github.com/stevesimmons/uuid7/issues/1 Any Python developer using the uuid7 library is getting something that is incompatible with the UUIDv7 specification and other UUIDv7 implementations as a result. Developers who use the stdlib uuid package in Python 3.14+ and uuid7 as a fallback in older versions are getting different, incompatible behaviour depending upon which version of Python they are running. This can manifest itself as a developer using UUIDv7 for its time-ordered property, deploying with Python <=3.13, upgrading to Python 3.14+ and discovering that all their data created with Python 3.13 sorts incorrectly when mixed with data created with Python 3.14+. A UUID library that is not receiving updates is quite possibly badly broken and definitely warrants suspicion and closer inspection.
    - 0x696C6961 7mo ago
      Alternative take: don't put draft RFCs into prod
      - JimDabell 7mo ago
        It hasn’t been a draft RFC for a couple of years: https://datatracker.ietf.org/doc/rfc9562/ https://datatracker.ietf.org/doc/rfc9562/ The problem is not that it is a draft RFC, the problem is that the library is unmaintained with an unresponsive developer who is squatting the uuid7 package name. It’s the top hit for Python developers who want to use UUIDv7 for Python 3.13 and below.
        0x696C6961 7mo ago
        The problem here is a lack of namespaces. A problem the cargo bozos decided to duplicate
        jrpelkonen 7mo ago
        Your point is completely invalidated by useless name calling. The people behind cargo are clearly accomplished and serious individuals, and even if you disagree with some of the choices, calling them bozos makes your whole argument unconvincing.
  - 8organicbits 7mo ago
    RFC changes aside, the go community has been bit by unmaintained UUID libraries with security issues. Consider https://github.com/satori/go.uuid/issues/123 https://github.com/satori/go.uuid/issues/123 as a popular example. The open issue in Google's repo about the package being malicious is not a good look. The community concluded it's a false positive. If the repo was maintained they'd confirm this and close the issue. Maintaince is much more than RFC compliance, although the project hasn't met that bar either.
  - mort96 7mo ago
    There have been committed 3 new features and a seemingly significant bug fix since the last release: https://github.com/google/uuid/compare/v1.6.0...HEAD https://github.com/google/uuid/compare/v1.6.0...HEAD If the library just existed as a correct implementation of the RFC without bugs or significant missing features, that would be one thing. But leaving features and bug fixes already committed to the repository unreleased for years because the maintainer hasn't cut a new release since 2024 is a bad sign.
0x696C6961 7mo ago
I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.
- ycombinatrix 7mo ago
  especially when they don't depend on libc.
PunchyHamster 7mo ago
The proposal is 3 years old

by kayson 7mo ago

da_chicken 7mo ago

While the uuid package is actively maintained, it hasn't had a release since 2024. Indeed, there's an open issue from June 2025 asking about it: https://github.com/google/uuid/issues/194 https://github.com/google/uuid/issues/194

rafram 7mo ago
The RFC isn’t changing, is it?
- JimDabell 7mo ago
  I’m not sure of the state of that particular library, but yes, the RFC has changed significantly. For instance, the UUIDv7 format changed from the earlier draft RFC resulting in incompatibilities. This is an example of an unmaintained UUID library in a similar situation that is currently causing incompatibilities because they implemented the draft spec. and didn’t update when the RFC changed: https://github.com/stevesimmons/uuid7/issues/1 https://github.com/stevesimmons/uuid7/issues/1 Any Python developer using the uuid7 library is getting something that is incompatible with the UUIDv7 specification and other UUIDv7 implementations as a result. Developers who use the stdlib uuid package in Python 3.14+ and uuid7 as a fallback in older versions are getting different, incompatible behaviour depending upon which version of Python they are running. This can manifest itself as a developer using UUIDv7 for its time-ordered property, deploying with Python <=3.13, upgrading to Python 3.14+ and discovering that all their data created with Python 3.13 sorts incorrectly when mixed with data created with Python 3.14+. A UUID library that is not receiving updates is quite possibly badly broken and definitely warrants suspicion and closer inspection.
  - 0x696C6961 7mo ago
    Alternative take: don't put draft RFCs into prod
    - JimDabell 7mo ago
      It hasn’t been a draft RFC for a couple of years: https://datatracker.ietf.org/doc/rfc9562/ https://datatracker.ietf.org/doc/rfc9562/ The problem is not that it is a draft RFC, the problem is that the library is unmaintained with an unresponsive developer who is squatting the uuid7 package name. It’s the top hit for Python developers who want to use UUIDv7 for Python 3.13 and below.
      - 0x696C6961 7mo ago
        The problem here is a lack of namespaces. A problem the cargo bozos decided to duplicate
        jrpelkonen 7mo ago
        Your point is completely invalidated by useless name calling. The people behind cargo are clearly accomplished and serious individuals, and even if you disagree with some of the choices, calling them bozos makes your whole argument unconvincing.
- 8organicbits 7mo ago
  RFC changes aside, the go community has been bit by unmaintained UUID libraries with security issues. Consider https://github.com/satori/go.uuid/issues/123 https://github.com/satori/go.uuid/issues/123 as a popular example. The open issue in Google's repo about the package being malicious is not a good look. The community concluded it's a false positive. If the repo was maintained they'd confirm this and close the issue. Maintaince is much more than RFC compliance, although the project hasn't met that bar either.
- mort96 7mo ago
  There have been committed 3 new features and a seemingly significant bug fix since the last release: https://github.com/google/uuid/compare/v1.6.0...HEAD https://github.com/google/uuid/compare/v1.6.0...HEAD If the library just existed as a correct implementation of the RFC without bugs or significant missing features, that would be one thing. But leaving features and bug fixes already committed to the repository unreleased for years because the maintainer hasn't cut a new release since 2024 is a bad sign.

0x696C6961 7mo ago

I get a kick out of publishing libs with no external deps. Regardless of reasoning, this change makes that easier.

ycombinatrix 7mo ago
especially when they don't depend on libc.

PunchyHamster 7mo ago

The proposal is 3 years old