Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UUID package coming to Go standard library

github.com

Post reply on HN
Print view View original

181–190 of 260 posts

Re: UUID package coming to Go standard library

#181

Post by 8organicbits »

sethammons wrote: post #144
gzread wrote: post #138

Earlier quoted context omitted.

You mean he could read it or he could write a parser or he could use a dependency?

Use a dependency. It was a wild pattern that still confuses me years later. Literal interview: concurrently hit these endpoints that returns json and sum the total of values returned. Handle any 400 or 500 level http errors. Literal former Googlers and flubbing the interview. They would spend too much time setting up an IDE and project, not be sure how to handle errors, and unable to parse the json. We eventually add…

The question evaluates different skills when you solve it in Java. If you allowed XML, you'd see Java candidates reach for the standard library, as it has a built-in XML parser. Using plain text responses was a good fix, as the candidate can focus on concurrency, networking, and error handling, which is probably what you were trying to assess.

Re: UUID package coming to Go standard library

#182

Post by talkin »

1f60c wrote: post #143
out_of_protocol wrote: post #114

Earlier quoted context omitted.

v7 exposes creation date, and maybe you don't want that. So, depends on use-case

I think I read something once about using v7 internally and exposing v4 in your API.

Or even an autoincrement int primary key internally. Depending on your scale and env etc, but still fits enough use cases.

Re: UUID package coming to Go standard library

#183

Post by 3eb7988a1663 »

isbvhodnvemrwvn wrote: post #155
0x696C6961 wrote: post #38

Earlier quoted context omitted.

It begs the question, why don't these languages put out a v2 stdlib?

Python had enough fun with 2 to 3 transition I think.

Honestly the problem was they did not go far enough. They hoped to have a minimal churn switch to avoid getting locked into bikeshedding for the rest of time. However, there was so little user user facing improvements that the required change hardly seemed worth porting. They also failed to initially offer any automatic porting tooling which could have increased adoption.

I will be forever mad that they did not use that as a breaking opportunity to namespace the standard library. Something like: `import std.io` so that other libraries can never conflict.

Re: UUID package coming to Go standard library

#184

Post by rollulus »

jasomill wrote: post #117
rollulus wrote: post #67

Earlier quoted context omitted.

Well that depends on your luck, it could be a valid one about 1/16th of the time.

1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble. The fact that we're discussing this at all is a reasonable argument for using a library function.

Nice, thanks and I agree.

Re: UUID package coming to Go standard library

#185

Post by 3eb7988a1663 »

jasomill wrote: post #117
rollulus wrote: post #67

Earlier quoted context omitted.

Well that depends on your luck, it could be a valid one about 1/16th of the time.

1/64, actually, because RFC-compliant (variant 1) UUIDv4 requires fixed values for both the version nibble and two bits of the variant nibble. The fact that we're discussing this at all is a reasonable argument for using a library function.

While it might be invalid, will most libraries choke if you give them a pseudo UUIDv4?

Re: UUID package coming to Go standard library

#186

Post by materielle »

azinman2 wrote: post #11
waynesonfire wrote: post #5

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?

I would really urge everyone to actually engage in the arguments people are making.

Go’s core design philosophy is stability. This means backwards compatibility forever. But really, even more than that. The community is largely against “v2” libraries. After the first version is introduced, Go devs trend towards stability, live with its flaws, and are super hesitant to fix things with a “v2”.

There have been exceptions. After 20 years of the frankly horrible json library, a v2 one is in the works.

Most of the uuid concerns come from a place of concern. After the api is added to the standard library, it will be the canonical api forever.

There are surely pros and cons to this design philosophy. I just don’t understand why people who disagree with Go’s core goals don’t just use a different language? Sorry to take a jab here, but are we really short on programming languages that introduce the wrong v1 api, so then the language ends up with codebases that depend on v1, v2, and v3? (Looking at you Java, Python, and C#)

Re: UUID package coming to Go standard library

#187

Post by pclmulqdq »

8organicbits wrote: post #150
pclmulqdq wrote: post #129

Earlier quoted context omitted.

I believe current official guidance if you want a lot of random data is to use v8, the "user-defined" UUID. The use of v4 is strictly less flexible here.

No, UUIDv8 offers 122 bits for vendor specific or experimental use cases. If you fill those bits randomly, you get the same amount of randomness as a v4. The spec is explicit that it does not replace v4 for random data use case. > To be clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all 122 extra bits are filled with random data. https://www.rfc-editor.org/rfc/rfc9562.html#section-5.8-2

Yes, vendor-specific data can be 100% random.

Re: UUID package coming to Go standard library

#188

Post by kbolino »

gethly wrote: post #146

Seems pointless. Go should focus on refactoring core libraries, especially net and http, for performance because nbio, gnet and others are kicking its ass. And that is sad, as third party libraries should never perform better than standard library. Also swiss tables were great addition to Go's native maps, but then again there are faster libraries that can give you 3x performance(in case of numeric keys).

From nbio's README:

  For regular connection scenarios, nbio's performance is inferior to the standard library due to goroutine affinity, lower buffer reuse rate for individual connections, and variable escape issues.
From gnet's README:

  gnet and net don't share the same philosophy in network programming. Thus, building network applications with gnet can be significantly different from building them with net, and the philosophies can't be reconciled.
  [...]
  gnet is not designed to displace the Go net, but to create an alternative in the Go ecosystem for building performance-critical network services.
Frankly, I think it's unfair to argue that the net package isn't performant, especially given its goals and API surface.

However, the net/http package is a different story. It indeed isn't very performant, though one should be careful to understand that that assessment is on relative terms; net/http still runs circles around some other languages' standard approaches to HTTP servers.

A big part of why net/http is relatively slow is also down to its goals and API surface. It's designed to be easy to use, not especially fast. By comparison, there's fasthttp [1], which lives up to its name, but is much harder to work with properly. The goal of chasing performance at all costs also leads to questionable design decisions, like fiber [2], based on fasthttp, which achieves some of its performance by violating Go's runtime guarantee that strings are immutable. That is a wild choice that the standard library authors would/could never make.

[1]: https://pkg.go.dev/github.com/valyala/fasthttp

[2]: https://pkg.go.dev/github.com/gofiber/fiber/v3

Re: UUID package coming to Go standard library

#189

Post by knorker »

grey-area wrote: post #160
KingOfCoders wrote: post #69

One thing I love about Go, not fancy-latest-hype features, until the language collapses or every upgrade becomes a nightmare, just adding useful stuff and getting out of the way.

I know, I recently upgraded and skipped several releases without any issues with some large codebases. The compatability guarantee is a massive win, so exciting to have a boring language to build on that doesn’t change much but just gradually gets better.

Really? My experience is that of C, C++, Go, Python, and Rust, Go BY FAR breaks code most often. (except the Python 2->3 change)

Sure, most of that is not the compiler or standard library, but dependencies. But I'm not talking random opensource library (I can't blame the core for that), but things like protobuf breaking EVERY TIME. Or x/net, x/crypto, or whatever.

But also yes, from random dependencies. It seems that language-culturally, Go authors are fine with breaking changes. Whereas I don't see that with people making Rust crates. And multiple times I've dug out C++ projects that I have not touched in 25 years, and they just work.

Re: UUID package coming to Go standard library

#190

Post by kstrauser »

tgv wrote: post #161
teeray wrote: post #156

Earlier quoted context omitted.

I just wish there was some human element to them so they were easier to talk about. Something like: BASKETBALL-9a176cbe-7655-4850-9e7f-b98c4b3b4704-FISH CAKE-3a01d58f-59d3-4b0c-87dc-4152c816f442-POTATO “Which row was it, ‘basketball fish’ or ‘cake potato’? Of course, the words would need to be a checksum. As soon as you introduce them, nobody is looking at the hex again. Which is an improvement, since nobody is looki…

There's nothing stopping you from doing so. You don't have to use strict UUIDs. Their form rarely serves a real purpose anyway. But for exposed values (document ids, customer ids, that kind of thing), it can be awkward if a patient's id is suddenly "CRANKY-...-FART".

If I discovered that were my patient ID, I would laugh myself into unconsciousness and buy the staff a pizza.
Post reply on HN