Live data from Hacker News

UUID package coming to Go standard library

github.com

21–30 of 260 posts

Re: UUID package coming to Go standard library

#21
Every time I read these types of Go issues, I think I am reading a writeup of a highschool debate club. It's like there is debate just for the sake of debate.

I understand the defensiveness about implementing new features, and I understand the rationale to keep the core as small as possible. But come on, it's not like UUID is a new thing. As the opener already pointed out, UUID is essential in pretty much all languages for interoperability so it makes sense to have that in the standard language.

Anyways, I'm just happy we'll get generic methods after 10 years of debates, I suppose. Maybe we'll get an export keyword before another 10, too. Then CGo will finally be usable outside a single package without those overlapping autogenerated symbols...

Re: UUID package coming to Go standard library

#22

what a bunch of drama in the comments.

It’s kind of ridiculous to argue against UUID being part of the standard package for a language largely aimed at servers. At that point why even have any crypto functions or any of the bigger stuff it already has if the argument is 3rd party libs are enough?

People are weird. A few days ago someone on /r/Java was arguing that a basic JSON parser shouldn’t be in the standard library.

Re: UUID package coming to Go standard library

#23
post #7

Golang lack of support for basic stuff like this is quite annoying.

What's the language you're thinking of that has more of these decisions fixed in the standard library? I know it's not Ruby, Python, Rust, or Javascript. Is it Java? I don't think this is something Elixir does better.

Perhaps I’m misunderstanding, but the linked issue seems to address this directly:

> Would like to point out how Go is rather the exception than the norm with regards to including UUID support in its standard library.

> C#: https://learn.microsoft.com/en-us/dotnet/api/system.guid.new...

> Java: https://docs.oracle.com/javase/8/docs/api/java/util/UUID.htm...

> JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/rand...

> Python: https://docs.python.org/3/library/uuid.html

> Ruby: https://ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/S...

Re: UUID package coming to Go standard library

#24
post #7

Golang lack of support for basic stuff like this is quite annoying.

What's the language you're thinking of that has more of these decisions fixed in the standard library? I know it's not Ruby, Python, Rust, or Javascript. Is it Java? I don't think this is something Elixir does better.

My first, and primary, programming language was C# which includes probably too large a standard library. It was definitely a surprise to see how minimal/simple other standard libraries are!

Re: UUID package coming to Go standard library

#25

Every time I read these types of Go issues, I think I am reading a writeup of a highschool debate club. It's like there is debate just for the sake of debate. I understand the defensiveness about implementing new features, and I understand the rationale to keep the core as small as possible. But come on, it's not like UUID is a new thing. As the opener already pointed out, UUID is essential in pretty much all languag…

Which is why I changed from being on Gonuts during pre-1.0 days to only touch Go if I really have to.

However I would still advocate for it over C in scenarios easily covered by TinyGo and TamaGo.

Re: UUID package coming to Go standard library

#26
A slow day in Go-news land? :)

It is heathwarming to see such mundane small tech bit making front page of HN when elsewhere is is debated whether programming as profession is dead or more broadly if AI will be enslaving humanity in the next decade. :)

Re: UUID package coming to Go standard library

#27
post #17

Earlier quoted context omitted.

The RFC isn’t changing, is it?

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/steve…

Alternative take: don't put draft RFCs into prod

Re: UUID package coming to Go standard library

#29
post #7

Earlier quoted context omitted.

What's the language you're thinking of that has more of these decisions fixed in the standard library? I know it's not Ruby, Python, Rust, or Javascript. Is it Java? I don't think this is something Elixir does better.

My first, and primary, programming language was C# which includes probably too large a standard library. It was definitely a surprise to see how minimal/simple other standard libraries are!

Like Python though, while the batteries are included, many of them are dead.

Re: UUID package coming to Go standard library

#30
post #2

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

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

especially when they don't depend on libc.
Post reply on HN