I think this gets at a major hurdle that needs to be overcome for truly human-level AGI.
Because the human brain is also non-deterministic. If you ask a software engineer the same question on different days, you can easily get different answers.
So I think what we want from LLMs is not determinism, just as that's not really what you'd want from a human. It's more about convergence. Non-determinism is ok, but it shouldn't be all over the map. If you ask the engineer to talk through the best way to solve some problem on Tuesday, then you ask again on Wednesday, you might expect a marginally different answer considering they've had time to think on it, but you'd also expect quite a lot of consistency. If the second answer went in a completely different direction, and there was no clear explanation for why, you'd probably raise an eyebrow.
Similarly, if there really is a single "right" answer to a question, like something fact-based or where best practices are extremely well established, you want convergence around that single answer every time, to the point that you effectively do have determinism in that narrow scope.
LLMs struggle with this. If you ask an LLM to solve the same problem multiple times in code, you're likely to get wildly different approaches each time. Adding more detail and constraints to the prompt helps, but it's definitely an area where LLMs are still far behind humans.
> To be clear, business operators have extremely, extremely broad latitude in how they interpret their fiduciary duty to shareholders.
That may be true legally, but practically it's only true if they control the board. Otherwise they will simply be replaced by people who are willing to do what the board wants.
The annoying tone is unnecessary. Yes, legally speaking operators can go against the board and get replaced, which they certainly should do if they feel they're being asked to do something unethical. But it's not going to change how the company is run.
For the executive, sure. Not for the impact of the overall incentive structure on the trajectory of the business. Which is what this discussion is about.
The root comment this thread is in reply to had the implication that people are only acting this way because of an inaccurate idea of how strict the legal obligations are, and the other comments are about how that’s obviously not the only force producing the current outcome
Yeah, obviously that's not "the only force producing this outcome." Nobody claimed it was.
But it's important for founders to understand they are not legally obligated to do any specific thing for their shareholders. It is their responsibility to act morally. Yes, there are other incentives and forces at play. "Legal obligation" is not the cop-out excuse that executives claim it is.
I think this attack makes it more likely they’ll get nukes, not less. They moved all their enriched uranium already, and now they know that there’s no longer any point in diplomacy.
The next facilities they build will be a few times deeper, and I have no doubt we’ll soon be hearing that ground troops are the only way to stop them.
They had already crossed the line into nuclear tech that's specifically for weapons, i.e. with a 400kg stockpile of uranium enriched to 60%. Unless we accept explanations like "scientific curiosity", they were already somewhere in the process of building nuclear weapons, even if success wasn't immanent.
I don't know how long these operations will set them back, but if the Iranian regime won't willingly refrain from nuclear weapons work, isn't a delay better than nothing?
They “could have” had nuclear weapons for a long time if they’d wanted to, yes, but they didn’t get them. They signed the NPT, allowed inspections, and their ruler issued a fatwa against developing nuclear weapons. Why’d they do all that if their goal all along was to get a nuclear weapon? They could have just done it.
These attacks make it clear that they would have been better off if they had gotten them, so it seems reasonable to assume this will be their new policy. What other strategic choice have they been left with?
Just to clarify, is your position that Iran was never working toward nuclear weapons, or just not until recently? I think enriching uranium to 60% is pretty clear evidence of their intent, even though it's just one component of an eventual weapon.
Being an NPT signatory could be evidence of Iran not working toward nuclear weapons, if they were compliant. But they have violated their NPT obligations on some occasions, with major violations recently.
I think they wanted to be seen as credibly close as a deterrent and bargaining chip in negotiations, but they had no intention of going all the way unless attacked.
Now they likely do intend to get them asap if they’re able to.
There isn't really such a thing as (forcefully) enforcing the NPT. Israel's casus belli (if we consider this a new war and not a continuation of one) would be based on self-defense.
60% enrichment is not weapons grade. Weapons grade is 80%. High enrichment is used in certain reactor designs, such as naval reactors.
There are a lot of reasons to be enriching uranium besides building nuclear weapons. Considering the US reneged on its deal to drop sanctions in exchange for Iran to not enrich uranium, it is pretty obviously useful as a bargaining chip, in the negotiations.
The US intelligence community assessed that Iran has not been working on a bomb since the program was shut down in 2003. They didn't want a nuke, they wanted an end to sanctions. They further wanted to avoid provoking exactly this sort of conflict. This did not delay them getting nuclear weapons, it will make them get nuclear weapons.
To quote an ISIS report, "Iran has no civilian use or justification for its production of 60 percent enriched uranium, particularly at the level of hundreds of kilograms". In theory it could be for naval propulsion, but experts (including IAEA inspectors) seem unconvinced.
Those can be bombed right at the beginning. Israel will probably try to establish a similar status que as in Lebanon right now - "if you make a move we immediately take it out".
And the development of a nuclear sites leaves a significant intelligence trail, not sure it can be hidden.
(Of course they can always be gifted a bomb, but that's a very different story)
Yeah I’m sure it will be a huge success with no unforeseen consequences whatsoever. Since that’s how these things have been going over the last thirty years.
That hardly entails that self-driving cars have "arrived". Am I mistaken or is it true that you can't even own and operate one yourself?
In my opinion, it's as similarly off-base as to making claims that 'mach speed consumer air travel' "arrived" just because for a few decades you could catch a Concorde flight between NYC and London.
I didn’t say they’ve arrived—I was just pointing out the very misleading “few” in your earlier comment. Anyone who spends an hour or two in SF can tell you how wrong that is. They’re literally everywhere.
You’re right that they have a long way to go before being fully mainstream. But thousands of people are using them every day in multiple major cities. That’s a pretty big milestone.
I built Plandex[1] (open source CLI coding agent focused on large projects and tasks) in Go and I’ve been very happy with that decision.
Beneath all the jargon, it’s good to remember that an “agent” is ultimately just a bunch of http requests and streams that need to be coordinated—some serially and some concurrently. And while that sounds pretty simple at a high level, there are many subtle details to pay attention to if you want to make this kind of system robust and scalable. Timeouts, retries, cancellation, error handling, thread pools, thread safety, and so on.
This stuff is Go’s bread and butter. It’s exactly what it was designed for. It’s not going to get you an MVP quite as fast as node or python, but as the codebase grows and edge cases accumulate, the advantages of Go become more and more noticeable.
Putting the merits of this specific case and positive vs. negative sentiments toward OpenAI aside, this tactic seems like it can be used to destroy any business or organization with customers who place a high value on privacy—without actually going through due process and winning a lawsuit.
Imagine a lawsuit against Signal that claimed some nefarious activity, harmful to the plaintiff, was occurring broadly in chats. The plaintiff can claim, like NYT, that it might be necessary to examine private chats in the future to make a determination about some aspect of the lawsuit, and the judge can then order Signal to find a way to retain all chats for potential review.
However you feel about OpenAI, this is not a good precedent for user privacy and security.
I'm confused at how you think that NYT isn't going through due process and attempting to win a lawsuit.
The court isn't saying "preserve this data forever and ever and compromise everyone's privacy," they're saying "preserve this data for the purposes of this court while we perform an investigation."
IMO, the NYT has a very good argument here that the only way to determine the scope of the copyright infringement is to analyze requests and responses made by every single customer. Like I said in my original comment, the remedies for copyright infringement are on a per-infringement basis. E.g., everytime someone on LimeWire downloads Song 2 by Blur from your PC, you've committed one instance of copyright infringement. My interpretation is that NYT wants the court to find out how many times customers have received ChatGPT responses that include verbatim New York Times content.
I don't think you're addressing my argument. If the "due process" destroys customer trust in the business being sued, regardless of the verdict, that's not really due process.
That's not entirely fair. The argument isn't "users are using the service to break the law" but rather "the service is facilitating law breaking". To fix your signal analogy suppose you could use the chat interface to request copyrighted material from the operator.
That doesn't change the outcome being the same in that the app has to send the plain text messages of everyone, including the chat history of every user.
Right. But requiring logs due to suspicion that the service itself is actively violating the law is entirely different from doing so on the basis that end users might be up to no good entirely independently.
Also OpenAI was never E2EE to begin with. They were already retaining logs for some period of time.
My personal view is that the court order is overly broad and disregards potential impacts on end users but it's nonetheless important to be accurate about what is and isn't happening here.
Again keep in mind that we are talking about a case limited analysis of that data within the privacy of the court system.
For example, if the trial happens to find data that some chats include crimes committed by users in their private chats, the court can't just send police to your door based on that information since the information is only being used in the context of an intellectual property lawsuit.
Remember that privacy rights are legitimate rights but they change a lot when you're in the context of an investigation/court proceeding. E.g., the right of police to enter and search your home changes a lot when they get a court issued warrant.
The whole point of E2EE services from the perspective of privacy-concious customers is that a court can get a warrant for data from those companies but they'll only be able to produce encrypted blobs with no access to decryption keys. OpenAI was always a not-E2EE service, so customers have to expect that a court order could surface their data to someone else's eyes at some point.
I think the issue is that "easier to follow the happy flow" basically also implies "easier to ignore the unhappy flow", and this is what a lot of people who have come to like Go's approach react against. We like that the error case takes up space—it's as important to deal with correctly as the happy path, so why shouldn't it take up space?
Is it 3x as important? Because currently, for a single line of happy path code you often have 3 lines of error handling code.
And while handling errors is important, it is also often trivial, just optionally wrapping the error and returning it up to the caller. I agree it is good for that to be explicit, but I don't think it needs to take up more space than the actual function call.
In my experience, the important error handling code is either at the lowest layer, where the error initiall occurs, or at the top level, where the error is reported to the user. Mid level code usually just propagates errors upwards.
Stack traces are full of noise by comparison and don't have context added by the programmer at each frame. For me, Go error chains are much easier to work with. I can see the entire flow of the error at a glance, and can zero in on the relevant call in seconds with a single codebase search.
Stack traces are not so long that you can't find the information you need in them, and actually just like go in some languages you can elect to add context to your stack trace (e.g. in python by raising an error from another error).
My experience in go was opposite of yours. The original devs (who were long gone) provided no information at all at the error site and I felt lucky even to find the place in the code that produced the error. Unfortunately the "force you to handle errors" idea, while well intentioned, doesn't "force you to provide useful error handling information", making it worse than stack traces by default.
They clearly are wrestling with these issues, which to me seems like taking the feedback seriously. Taking feedback seriously doesn’t imply you have to say yes to every request. That just gives you a design-by-committee junk drawer language. We already have enough of those, so personally I’m glad the Go team sticks to its guns and says no most of the time.
How is Go not a design-by-committee language? They don't have a single lead language developer or benevolent dictator, and as this blog demonstrates, they're very much driven by consensus.
I have no problem with Go’s error handling. It’s not elegant, but it works, and that’s very much in keeping with the pragmatic spirit of Go.
I’m actually kind of surprised that it’s the top complaint among Go devs. I always thought it was more something that people who don’t use Go much complain about.
My personal pet issue is lack of strict null checks—and I’m similarly surprised this doesn’t get more discussion. It’s a way bigger problem in practice than error handling. It makes programs crash in production all the time, whereas error handling is basically just a question of syntax sugar. Please just give me a way to mark a field in a struct required so the compiler can eliminate nil dereference panics as a class of error. It’s opt-in like generics, so I don’t see why it would be controversial to anyone?
It's too easy to accidentally write `if err == nil` instead of `if err != nil`. I have even seen LLMs erroneously generate the first instead of the latter. And since it's such a tiny difference and the code is riddled with `if err != nil`, it's hard to catch at review time.
Second, you're not forced by the language to do anything with the error at all. There are cases where `err` is used in a function that not handling the `err` return value from a specific function silently compiles. E.g.
x, err := strconv.Atoi(s1)
if err != nil {
panic(err)
}
y, err := strconv.Atoi(s2)
fmt.Println(x, y)
I think accidentally allowing such bugs, and making them hard to spot, is a serious design flaw in the language.
I guess those are fair criticisms in the abstract, but personally I can’t recall a single time either has caused a bug for me in practice. I also can’t ever recall seeing an LLM or autocomplete mess it up (just my personal experience—I’m sure it can happen).
> It’s opt-in like generics, so I don’t see why it would be controversial to anyone?
It "breaks" the language in fundamental ways — much more fundamental than syntactic sugar for error handling — by making zero values and thus zero initialisation invalid.
You even get this as a fun interaction with generics:
I don’t see how it breaks anything if it’s opt-in. By default you get the current behavior with zero value initialization if that’s what you want (and in many cases it is). But if you’d rather force an explicit value to be supplied, what’s the harm?
If it would only complain on struct literals that are missing the value (and force a nil check before access if the zero value is nil to prevent panics), that would be enough for me. In that case, your Zero function and reflect.Zero can keep working as-is.
Because the human brain is also non-deterministic. If you ask a software engineer the same question on different days, you can easily get different answers.
So I think what we want from LLMs is not determinism, just as that's not really what you'd want from a human. It's more about convergence. Non-determinism is ok, but it shouldn't be all over the map. If you ask the engineer to talk through the best way to solve some problem on Tuesday, then you ask again on Wednesday, you might expect a marginally different answer considering they've had time to think on it, but you'd also expect quite a lot of consistency. If the second answer went in a completely different direction, and there was no clear explanation for why, you'd probably raise an eyebrow.
Similarly, if there really is a single "right" answer to a question, like something fact-based or where best practices are extremely well established, you want convergence around that single answer every time, to the point that you effectively do have determinism in that narrow scope.
LLMs struggle with this. If you ask an LLM to solve the same problem multiple times in code, you're likely to get wildly different approaches each time. Adding more detail and constraints to the prompt helps, but it's definitely an area where LLMs are still far behind humans.
reply