undefined

points

[-]

UUIDv7 didn't mature until long after the Go standard library was mostly settled. By that point, there was already an idiomatic 3p dep for UUIDs (the Google package), and as you can see from the thread, there were arguments in favor of keeping it 3p (it can be updated on an arbitrary cadence, unlike the stdlib).

by azinman218 hours ago|

parent|

[-]

They could have implemented the other types of uuid generation, as well as having the standard type. Then evolve.

UUIDs rarely get new versions. I don’t think it’d be too much to expect Go to stay relatively current on that.

by vips7L19 hours ago|

prev|

[-]

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.

by sethammons14 hours ago|

parent|

[-]

Anecdote: about 8 years ago, I was interviewing hundreds of candidates for a non-java shop but you could interview in java if desired. One java dev ever was able to figure out parsing json with ease. Every single other java interview the person struggled with json. It was weird.

by gzread12 hours ago|

parent|

[-]

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

by sethammons12 hours ago|

parent|

[-]

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 added a skeleton java project and removed json from the api, allowing text only responses. I learned java people don't set up projects or deal with json. It is the only explanation

by fl0ki9 hours ago|

parent|

[-]

"Former Googlers" were probably used to using protobuf so they could get from a function call straight out to a struct of the right schema. It's one level of abstraction higher and near-universal in Google, especially in internal-to-internal communication edges.

I don't think it's a strong hiring signal if they weren't already familiar with APIs for (de)serialization in between, because if they're worth anything then they'll just pick that up from documentation and be done with it.

by 8organicbits8 hours ago|

parent|

prev|

[-]

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.

by vips7L6 hours ago|

parent|

prev|

[-]

In my experience it’s Googler’s not Java people. All of my friends at Google tell me how everything is already set up for them.

by a577219 hours ago|

parent|

prev|

[-]

You mention it was 8 years ago, at that point a typical Java dev would be already using Spring Boot for requests and deserializing JSON to POJOs (with Jackson under the hood).

by hrmtst9383718 hours ago|

prev|

[-]

Adding UUID to the standard library is defensible for a server-focused language, but making it part of the stdlib binds maintainers to long-term compatibility and support, so the debate should focus on API surface and long term maintenance rather than whether third-party packages exist.

If added, keep the scope small: implement RFC 4122 v4 generation using crypto/rand.Read with correct version and variant bit handling, provide Parse and String, MarshalText and UnmarshalText, JSON Marshal and Unmarshal hooks, and database/sql Scanner and Valuer, and skip v1 MAC and time based generation by default because of privacy and cross-platform headaches.

by materielle8 hours ago|

prev|

[-]

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#)