4 ms·
what a bunch of drama in the comments.
by waynesonfire 7mo ago
what a bunch of drama in the comments.
- rednafi 7mo agoBasically one guy having a fit when people disagreed with him.
- fractorial 7mo agoIt would appear that person and OP are one in the same.
- tptacek 7mo agohttps://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email
- azinman2 7mo agoIt’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?
- tptacek 7mo agoUUIDv7 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).
- azinman2 7mo agoThey 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.
- vips7L 7mo agoPeople are weird. A few days ago someone on /r/Java was arguing that a basic JSON parser shouldn’t be in the standard library.
- sethammons 7mo agoAnecdote: 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.
- gzread 7mo agoYou mean he could read it or he could write a parser or he could use a dependency?
- sethammons 7mo agoUse 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
- fl0ki 7mo ago"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.
- hrmtst93837 7mo ago[flagged]
- materielle 7mo agoI 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#)
- throwaway894345 7mo agoWelcome to literally any Go thread.