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#)
Fair deal for the employees but hard to compete against smart, well resourced people who are working 996. Everything with AI is moving so fast that moving slower makes you irrelevant.
Would be a nightmare to implement and achieve the goal, but I have to say I think it’s more right than wrong. All of the data is very clear about the harms.
China has restrictions for social media and screen time for kids — how do they implement this?
I actually think this would be easier to implement than many of the current ID verification methods I've seen being pushed. We already have the infrastructure for selling age restricted goods, this is nothing new. Manufacturers that are unable to restrict their hardware in a "child" mode don't have to do anything and could simply continue selling to adults only.
It's obvious we're moving in a direction where we are going to get these restrictions in one way or another, and this is the only way I've come up with that doesn't come with serious privacy implications.
Most importantly, this solution would be simple for anyone to understand. You don't need to be a cryptography expert to understand there are child safe devices and then there are unrestricted devices for adults.
Would the parents comply though? Many of the restrictions work because most adults agree is OK. For example for alcohol, children could drink as much as they want at home, if adults would permit it.
If most adults would be convinced there is an issue, one probably has enough lock-down modes even nowadays, not sure it is a "technical" problem.
I strongly believe that most would actually. All parents I've talked to have had issues with parenting their children's online activity. They know there are harmful things they want to prevent them from accessing but it is simply to hard to configure and set up existing tools for it. (Besides every single friend they have don't have any restrictions so it all seem pointless.)
I can also see also large support for uploading ID to various services when talking about kids, but when you re-frame the question to adults, most seems to really dislike the idea immensely.
Sure there will be children with access to unrestricted devices, just like we had kids with porn mags hidden in a forest somewhere back in the day, or how that one sketchy guy was buying alcohol, etc. But I think this is an acceptable level of risk for whatever harm people want to prevent.
Definitely makes it easier for parents. It also normalizes screen time limits for kids. When none of your kids' friends have screen time limits, it's harder to enforce. When at least there's a few of them, it's easier to get buy-in from your kids.
At that point it's on the parents. We can't stop parents from giving their kids alcohol or drugs either. (Not saying internet access is necessarily on the same level as that but you get the point.)
Consider that even with something as divisive as covid lockdowns and vaccines, the overwhelming majority of people complied with government instructions.
There are a minority of people currently refusing to vaccinate their children properly, and their fucking around is being found out with measles outbreaks in various countries.
Why would this be different? Why wouldn't it be a minority of parents permitting their children to drink, to smoke, to use unrestricted computing resources?
Oh, that actually seems ... bad. On the gripping hand... restricted in which way? I learned to program on the BBC B, for instance.
I keep thinking that computers that are actually made to be good for children should be a thing. Perhaps like "A Young lady's Illustrated Primer" ( https://en.wikipedia.org/wiki/The_Diamond_Age )
It's a nightmare to some extent to prevent underage people from consuming alcohol if you want to phrase it that way. But we don't try to ban stores from selling alcohol because of concerns children will be drinking it. Instead we require the store checks for ID.
Which has never worked. Korea had a system to prevent kids from gaming after midnight for something like 15 years. All it did was make Korean kids very good at memorizing their parents ID.
In China they link the ID to a phone number (via mobile carriers) and the online services require you to authenticate using the phone (SMS etc.) Unless the kids are able to secretly access the parent's phone there's no low-effort way to work around the system.
I don't know about Korea but if memorizing an ID number works, then that's just a badly designed system.
I'm not sure what your argument is really, unless you're saying there's technically and absolutely no feasible way to securely verify the age of a person before allowing them to access an online service (even if you allow the government to be authoritarian)
when i signed up for mobile service or for internet service in china (i don't remember the specifics), i was given half a dozen sim cards for use in my family. so they were all tied to my or my wife's name, but used by anyone who needed one. i believe the in-laws got at least one or two, and my kids would have gotten one, had they been old enough to have their own phone. i don't know if there was any rule that would restrict who we give those cards.
the actual users of each simcard did not have to identify themselves. so at least then it wasn't about age controls, but it obviously would allow tracing the owner eventually.
Maybe it does work exactly as intended. It gives parents more leverage to restrict their kids gaming but many parents just don't care. And it's ok I guess, the society probably needs some flexibility in raising the next gen.
Good ideas can come from anywhere. Shutting yourself off only does a disservice. You don’t need to replicate 100% of another society to recognize individual strengths.
Yeah, sounds like something from an authoritarian police state.
> Essentially, this is a cross-platform, cross-device, government-led parental control system that has been painstakingly planned out by Beijing.
> The rules are incredibly specific: kids under eight, for instance, can only use smart devices for 40 minutes every day and only consume content about “elementary education, hobbies and interests, and liberal arts education”; when they turn eight, they graduate to 60 minutes of screen time and “entertainment content with positive guidance.” Honestly, this newsletter would have to go on forever to explain all the specifics.
We don’t do this in free societies. Let the parents decide.
A bit strange to use time to first token instead of throughput.
Latency to the first token is not like a web page where first paint already has useful things to show. The first token is "The ", and you'll be very happy it's there in 50ms instead of 200ms... but then what you really want to know is how quickly you'll get the rest of the sentence (throughput)
As far as benchmarketing goes they clearly went with prefill because it's much easier for apple to improve prefill numbers (flops-dominated) than decode (bandwidth-dominated, at least for local inference); M5 unified memory bandwidth is only about 10% better than the M4.
To add to the sibling "good is relative" it also depends what you're running, not just your relative tolerances of what good is. E.g. in a MoE the decode speedup means the speed of prompt processing delay is more noticeable for the same size model in RAM.
Not strange, for the kind of applications models at that size are often used for the prefill is the main factor in responsiveness. Large prompt, small completion.
No you don't. Not as a sticky mushy human with emotions watching tokens drip in. There's a lot of feeling and emotion not backed by hard facts and data going around, and most people would rather see something happening even if it takes longer overall. Hence spinner.gif, that doesn't actually remotely do a damned thing, but it gives users reassurance that they're waiting for something good. So human psychology makes time to first token an important metric to look at, although it's not the only one.
reply