The explanation for the headaches is that coffee raises blood pressure short term, and the blood vessels in the brain prepare for the predicted caffeine ingestion, and if it doesn't come there will be a mismatch.
What triggers the blood vessel constriction on the brain? Will avoiding e.g. certain places at certain hours also avoid the preemptive blood vessel constriction and associated headache?
That's called chemical dependence and it's the point I'm trying to make. Dependence is not addiction. Addiction means wanting is hijacked, not that stopping is aversive.
Addiction and dependence have real medical meanings and in the context of this discussion and we shouldn't mix them up. See this very short and to the point lancet medical journal summary, https://www.thelancet.com/journals/lanpsy/article/PIIS2215-0...
>Addiction (synonymous with substance use disorder), as defined by the DSM-5, entails compulsive use, craving, and impaired control over drug taking in addition to physical dependence. The vast majority of patients taking medications such as opioids and benzodiazepines are doing so as prescribed by clinicians, with only 1·5% of people taking benzodiazepine being addicted, for example. Physical dependence is much more common than addiction. Importantly, withdrawal effects occur irrespective of whether these drugs are taken as prescribed or misused.
>Failure to distinguish between addiction and physical dependence can have real-life consequences. People who have difficulty stopping their medications because of withdrawal effects can be accused of addiction or misuse. Misdiagnosis of physical dependence as addiction can also lead to inappropriate management, including referral to 12-step addiction-based detoxification and rehabilitation centres, focusing on psychological aspects of harmful use rather than the physiology of withdrawal.
>It should be made clear that dependence is not the same as addiction. The problems with prescribed drug dependence are not restricted to the small minority who are misusing or addicted to these drugs, but to the wider population who are physically dependent on and might not be able easily to stop their medications because of withdrawal effects. Antidepressants (superkuh note: and caffeine) should be categorised with other drugs that cause withdrawal syndromes as dependence-forming medications, while noting that they do not cause addiction.
I thought ocaml programs were a little confusing about how they are structured. Also the use of Let wasn't intuitive. go and rust are both still pretty much c style
How is a stack trace with line numbers and a message for the exception it self not enough information for why an exception was thrown?
The exceptions from something like open are always pretty clear. Like, the files not found, and here is the exact line of code and the entire call stack. what else do you want to know to debug?
It's enough information if you are happy to have a fragile API, but why would you purposefully make life difficult not only for yourself, but the developers who have their code break every time you decide to change something that should only be an internal implementation detail?
Look, if you're just writing a script that doesn't care about failure — where when something goes wrong you can exit and let the end user deal with whatever the fault was, you don't have to worry about this. But Go is quite explicitly intended to be a systems language, not a scripting language. That shit doesn't fly in systems.
While you can, of course, write systems in Python, it is intended to be a scripting language, so I understand where you are coming from thinking in terms of scripts, but it doesn't exactly fit the rest of the discussion that is about systems.
That makes even less sense becasue go errors provide even less info other then a chain of messages. They might as well be lists of strings. You can maybe reassbmle a call stack your self if all of the error handlers are vigalente about wrapping
> That makes even less sense becasue go errors provide even less info other then a chain of messages.
That doesn't make sense. Go errors provide exactly whatever information is relevant to the error. The error type is an interface for good reason. The only limiting bound on the information that can be provided is by what the computer can hold at the hardware level.
> They might as well be lists of strings.
If a string is all your error is, you're doing something horribly wrong.
Or, at very least, are trying to shoehorn Go into scripting tasks, of which it is not ideally suited for. That's what Python is for! Python was decidedly intended for scripting. Different tools for different jobs.
Go was never designed to be a scripting language. But should you, for some odd reason, find a reason to use in that that capacity, you should at least being using its exception handlers (panic/recover) to find some semblance of scripting sensibility. The features are there to use.
Which does seem to be the source of your confusion. You still seem hung up on thinking that we're talking about scripting. But clearly that's not true. Like before, if we were, we'd be looking at using Go's exception handlers like a scripting language, not the patterns it uses for systems. These are very different types of software with very different needs. You cannot reasonably conflate them.
Chill with being condescending if you want a discussion.
The error type in go is literally just a string
type error interface {
Error() string
}
That's the whole thing.
So i dont know what your talking about then.
The wrapped error is a list of error types. Which all include a string for display. Displaying an error is how you get that information to the user.
If you implement your own error, and check it with some runtime type assertion, you have the same problem you described in python. Its a runtime check, the API your relying on in whatever library can change the error returned and your code won't work anymore. The same fragile situation you say exists in python. Now you have even less information, theres no caller info.
No, like I said before, it's literally an interface. Hell, your next line even proves it. If it were a string, it would be defined as:
type error string
But as you've pointed out yourself, that's not its definition at all.
> So i dont know what your talking about then.
I guess that's what happens when you don't even have a basic understanding of programming. Errors are intended to be complex types; to capture all the relevant information that pertains to the error. https://go.dev/play/p/MhQY_6eT1Ir At very least a sentinel value. If your error is just a string, you're doing something horribly wrong — or, charitably, trying to shoehorn Go into scripting tasks. But in that case you'd use Go's exception handlers, which bundles the stack trace and all alongside the string, so... However, if your workload is script in nature, why not just use Python? That's what it was designed for. Different tools for different jobs.
They should have made the point about knowing where errors will happen.
The cherry on top is that you always have a place to add context, but it's not the main point.
In the Python example, anything can fail anywhere. Exceptions can be thrown from deep inside libraries inside libraries and there's no good way to write code that exhaustively handles errors ahead of time. Instead you get whack-a-mole at runtime.
In Go, at least you know where things will fail. It's the poor man's impl of error enumeration, but you at least have it. The error that lib.foo() returned might be the dumbest error in the world (it's the string "oops") but you know lib.foo() would error, and that's more information you have ahead of time than in Python.
In Rust or, idk, Elm, you can do something even better and unify all downstream errors into an exhaustive AGDT like RequestError = NetworkError(A | B | C) | StreamError(D | E) | ParseError(F | G) | FooError, where ABCDEFG are themselves downstream error types from underlying libraries/fns that the request function calls.
Now the callsite of `let result = request("example.com")` can have perfect foresight into all failures.
I don't disagree that exceptions in python aren't perfect and rust is probably closest of them all to getting it right (though still could be improved). I'm just saying stack traces with exceptions provide a lot of useful debugging info. IMO they're more useful then the trail of wrapped error strings in go.
exceptions vs returned errors i think is a different discussion then what im getting at here.
I disagree, adding context to errors provide exactly what is needed to debug the issue. If you don't have enough context it's your fault, and context will contain more useful info than a stack trace (like the user id which triggered the issue, or whatever is needed).
Stack traces are reserved for crashes where you didn't handle the issue properly, so you get technical info of what broke and where, but no info on what happened and why it did fail like it did.
It's one piece of information, but logging at the error location does that still. And if you have a function that's called in multiple places how do you know the path that got you into that place. If it wasn't useful we wouldn't try to recreate them with wrapped errors
You wrap errors primarily to avoid the implementation detail leak. Even where errors have stack traces, you still need to do that, as was already described earlier. What debugging advantage comes with that is merely an aded bonus (A really nice bonus, to be sure. Attaching stack traces is computationally wasteful, so it is a win to not have to include them).
You can get away with not doing that when cowboy coding scripts. Python was designed to be a scripting language, so it is understandable that in Python you don't often need to worry about it. But Go isn't a scripting language. It was quite explicitly created to be a systems language. Scripts and systems are very different types of software with very different needs and requirements. If you are stuck thinking in terms of what is appropriate for scripting, you're straight up not participating in the same thread.
> I'm just saying stack traces with exceptions provide a lot of useful debugging info.
The Go team actually did a study on exactly that; including stack traces with errors. Like you, they initially thought it would be useful (hence the study), but in the end, when the data was in, they discovered nobody ever actually used them. Meaningful errors proved to be far more useful.
Science demands replication, so if your study disagrees, let's see it. But in the absence of that, the Go study is the best we've got and it completely contradicts what you are telling us. Making random claims up on the spot based on arbitrary feelings isn't indicative of anything.
That said, I think we can all agree there is a limited place for that type of thing (although in that place you shouldn't use Go at all — there are many other languages much better suited to that type of problem space), but in that place if you had to use Go for some strange reason you'd use panic and recover which already includes the stack trace for you. The functionality is already there exactly as you desire when you do need to bend Go beyond what it is intended for.
Shipping the frontend for features in a core product area on a large team, just like a lot of other devs here :)
To go into specifics of actual problems solved and do so intelligibly, I'd have to provide specific context, which I'm not comfortable doing here.
It's a lot easier to describe "interesting problems solved" using less identifiable (and more generally interesting) details if one is in platform/infra and/or operating at a Staff+ level -- both of which I have been in the past (and loved it), but am not at the moment.
I'm pretty sure no one is going to be hunting down NDA infractions on HN unless the poster is silly enough to give specifics about the workplace and time at which they solved the problem. If it takes some kind of investigative work to piece together the most basic details, I think that's within the terms of most NDAs anyway.
One of the last times I commented in a thread like this, someone looked at my profile (which has my real name), found me on LinkedIn, and then posted my employer's name in a reply to me, calling out an alleged conflict of interest (you can find it in my comment history and make a decision on that for yourself, if you're curious).
It's not worth the internet points for any of us to post details beyond what we do.
Airbnb has ~$12 bn annual revenue, and is a counterexample to the idea that no companies can be "convinced to use DeepSeek".
The fact that it's customer service means it's dealing with text entered by customers, which has privacy and other consequences.
So no, it's not "pretty inconsequential". Many more companies fit a profile like that than whatever arbitrary criteria you might have in mind for "consequential".
reply