kiitos

21 ms·

301.
by kiitos 1y ago
I know ..! Ignoring an error at a call site is a bug by the caller, that Go requires teams to de-risk via code review, rather than via the compiler. This is well understood and nobody disputes it. And yet all available evidence indicates
302.
by kiitos 1y ago
> Go really wants you to define a type that you can cast or switch on, which is far better. Go very very much does not want application code to be type-asserting the values they receive. `switch x.(type)` is an escape hatch, not a normal
303.
by kiitos 1y ago
> t is deeply inefficient. As() traverses the cause tree recursively for every single error, so if you have 30 possible error types to compare, and an error typically wraps 3 layers deep, that's a worst case of 30 loop iterations wi
304.
by kiitos 1y ago
It literally is not. Is and As are not merely convenience functions, they're canonical and conventional expectations of Go code, if you're doing that work yourself you're almost certainly doing it wrong.
305.
by kiitos 1y ago
I'm not sure why you're equivocating "all code" with "CRUD apps". If that were the case I'd be with you. But it isn't. Glue code between APIs is indeed pointless garbage that can be automated, but tha
306.
by kiitos 1y ago
> Returning bogus values alongside errors. Unless documented otherwise, a non-nil error renders all other return values invalid, so there's no real sense of a "bogus value" alongside a non-nil error. > Designing the er
307.
by kiitos 1y ago
Is this not... embarrassing? to the engineers who submit these commits? It seems that way to me... Certainly if I were on a hiring panel for anyone who had this kind of stuff in their Google search results, it would be a hard-no from me --
308.
by kiitos 1y ago
> Rust was designed smarter from the start I guess this makes it pretty clear that there's no useful conversation to be had with you on this topic. > (In point of fact you shouldn't use fmt.Errorf if you're serious abou
309.
by kiitos 1y ago
This code: foo, err := someExpr if err != nil { return nil, err } Is entirely boilerplate But you'd never write that, you'd write if err != nil { return nil, fm
310.
by kiitos 1y ago
You're simply wrong. If I call a function and it fails, then at the base level it doesn't matter if it failed because "no more disk space" or because "input values are invalid" -- the thing failed, in both case
311.
by kiitos 1y ago
I read this article completely thru, twice, and I still have no idea what the author is trying to say. All I can read here is a bunch of sarcastic dismissals of stuff that I don't believe and have no way to evaluate.
312.
by kiitos 1y ago
Time spent typing is statistically 0% of overall time spent in developing/implementing/shipping a feature or product or whatever. There's literally no reason to try to optimize that irrelevant detail.
313.
by kiitos 1y ago
Errors are just values, same as other values, it's in no way "exceptional" for a caller to get an error back from a call to some other code. If a function can fail it needs to return an error, if a function call fails the cal
314.
by kiitos 1y ago
Paste exactly what commands you run and exactly their output, including exactly the rev of the repo you're running them in. > Remove the file and the error disappears Remove the file and the code no longer compiles, because the file
315.
by kiitos 1y ago
If a function `func foo() (int, error)` returns a non-nil error, then the corresponding `int` is absolutely invalid and should never be evaluated by the caller, unless docs explicitly say otherwise.
316.
by kiitos 1y ago
It's just simply not the cause that error handling is an "entirely boilerplate operation", nor that any kind of macro in Go "would be less terrible" than the status quo, nor is it true that decisions that Rust made
317.
by kiitos 1y ago
Programming languages are designed systems, they need to make sense holistically. They're not simply collections of tick-boxed features that are expected to be added once their tick-box requirements are satisfied.
318.
by kiitos 1y ago
Currently if you want to return from a function/method you need to type `return` in the source code. And return is a single expr, it can't be chained or embedded, and in almost all cases it exists on its own line in the file. This
319.
by kiitos 1y ago
If you're re-implementing errors.As's unwrapping behavior in your application code in order to parse/evaluate errors, that's a mistake and a design error. You'd never call Unwrap outside of a custom error type'
320.
by kiitos 1y ago
`err.(type)` is incorrect, at least in general. Calling `errors.Unwrap` in application code like this is almost always a red flag indicating a design error. And in this case it definitely is!
321.
by kiitos 1y ago
Sure, but nobody is gonna rely on TSAN to determine data races in their code :)
322.
by kiitos 1y ago
> The answer to your questions is that timing is not the issue in my example. You can notice this easily if you strip std::atomic<> from the type. TSAN can and does catch it just fine. If you strip the std::atomic from your example
323.
by kiitos 1y ago
It's not that the example is incomplete, it's that it's incorrect! :)
324.
by kiitos 1y ago
Assuming a stable connection, there is no meaningful performance difference between a request/response round-trip from the client to the server, and a response streamed from the server to the client, amortized over time.
325.
by kiitos 1y ago
And an important part about publishing your own thoughts to a broader audience is evaluating feedback from that audience rather than dismissing it :)
326.
by kiitos 1y ago
An interview process that allows a single individual to have absolute veto power over multiple prior interview evaluators is, pretty obviously, broken.
327.
by kiitos 1y ago
Most of the folks that I've worked with, who have previously worked at Canonical, have been categorically unimpressive. "Senior" engineers with limited, even naive, understanding of the technologies and tools they're wor
328.
by kiitos 1y ago
Hopefully with some kind of synchronization, since errctx is pretty clearly not safe for concurrent use by multiple goroutines.. !
329.
by kiitos 1y ago
You've linked to papers that define "data race" in a specific way. That doesn't mean that when anyone says "data race" in any other context they are using any of those papers' definitions, for reasons that
330.
by kiitos 1y ago
err.(type) fails when errors are wrapped, which is common and needs to be accommodated. To do what you're trying to do, you need to use errors.As.

More ›