> my whole career using regex and never fully grokking it
Sorry to hear that, nobody ever told me either. Had you invested a bit of time earlier in your career, it would have paid dividends 100x fold. The key is knowing what’s wheat and what’s chaff. Regex is a wheat.
With that said, maybe you tried.. everyone has their limits.
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?
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).
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.
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
"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.
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.
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).
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.
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#)
This is the correct answer. Anything proprietary phones home and inserts malicious metadata into pictures that allow others (social media) to know who, when and how the photo was taken.
You can even use the proprietary Pixel Camera on GrapheneOS and just deny network permissions, or if you’re worried about IPC (if you have another networked Google app installed) it can be in its own private space. And then just strip the exif data if you want before sending it anywhere.
Its an order of magnitude difference in what it can do, mostly because it can verify its own work. It can also use subagents which helps a lot. Large tasks I usually have done by subs with the main agent directing. This means the task they can take on can be much larger.
I'm in the same boat as waynesonfire and I'm afraid this doesn't answer the question sufficiently. What do you do with an agent? What's a concrete example vs. typing in a chat box.
When you have workflows that you repeat over and over it’s easier to formalize with something like jido. Ie if you don’t want to type into a checkbox and verify output everytime.
If hadoop did it, so can you. I'm talking about a project that stretched Java 8 to, and arguably beyond, its intended operational boundaries. Unlikely that you’re leaning on this boundary. It's Spring Boot upgrades that will be giving you troubles.
If you’re hiring for a UX / product hybrid, I’d welcome the opportunity to connect you with a candidate.
They operate fluently across user research, synthesis, and interaction design — but more importantly, they are disciplined about ensuring the team is solving the right problem before optimizing the solution. Strong conviction around first-principles framing, epistemic rigor, and problem selection as leverage.
Core strengths:
- Structured discovery and incisive problem definition
- Translating ambiguous signals into coherent product theses
- Systems-level thinking across UX, engineering, and business constraints
- Driving execution with clarity, precision, and accountability
A thinker who prizes discernment over velocity and correctness over noise.
If your team values intellectual honesty, strategic acuity, and taste, I’m happy to make an introduction.
The more I try to use these tools to push up this "ladder" the more it becomes clear the technology is a no more than a 10x better Google search.
reply