Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Error return traces for Go, inspired by Zig

github.com

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Show HN: Error return traces for Go, inspired by Zig

#81

Post by lsaferite »

wwarner wrote: post #58
zgk7iqea wrote: post #56

go is step by step reinventing exceptions

go basically has exceptions with panic & recover. and it’s perfectly simple to add stack traces to errors, should you want it.

That completely misses the fact that you need the providers of the code several layers away from you to make those choices and they frequently don't.

I can add stack traces and raise panics all day long in my code and it will never help me trace a deep error in my system. The collective blindness to that in the go world is staggering.

Re: Show HN: Error return traces for Go, inspired by Zig

#82

Post by [deleted] »

lsaferite wrote: post #80
bensecure wrote: post #69

Earlier quoted context omitted.

the go type has the implicit restriction that if error is true, then the result is meaningless. So really it has 3 meaningfully distinct values.

> implicit restriction that if error is true, then the result is meaningless By 'implicit' I assume you mean 'by convention'? I say this because unless I've misread the go spec (and that's a distinct possibility), function returns are either a single value or a tuple and there is no specification on tuple returns and mutually exclusive values. FWIW, I mostly like go and work with it practically every day. I absolutel…

[deleted]

Re: Show HN: Error return traces for Go, inspired by Zig

#83

Post by ForkMeOnTinder »

throwawaymaths wrote: post #63
ForkMeOnTinder wrote: post #30

Earlier quoted context omitted.

And what's funny about that stance is mathematical operators aren't actually O(1). https://en.wikipedia.org/wiki/Computational_complexity_of_ma... You don't want to know what the innocent-looking `*` in this function compiles to: fn square(num: u10000) u10000 { return num * num; }

Is the underlying algo not O(1)? Under what pairs of two u10000 numbers would you get different execution time?

Sure, if you ignore the n in n=10000, multiplication is O(1). But the same is true for e.g. heapsort--all lists of 10000 items take asymptotically the same amount of time to sort.

But that's a strained interpretation of complexity, and not very useful.

Re: Show HN: Error return traces for Go, inspired by Zig

#84

Post by randomdata »

lsaferite wrote: post #80
bensecure wrote: post #69

Earlier quoted context omitted.

the go type has the implicit restriction that if error is true, then the result is meaningless. So really it has 3 meaningfully distinct values.

> implicit restriction that if error is true, then the result is meaningless By 'implicit' I assume you mean 'by convention'? I say this because unless I've misread the go spec (and that's a distinct possibility), function returns are either a single value or a tuple and there is no specification on tuple returns and mutually exclusive values. FWIW, I mostly like go and work with it practically every day. I absolutel…

> I absolutely loathe it's ideas on error handling.

Its idea is simply that error is just state like any other. I find that to be quite reasonable – and something I miss dearly when I work in other languages which try to get overly fancy to try and hide that fact. There is nothing special about errors. The machine certainly has no concept of errors. Why does it need special constructs?

Bad practices like assuming T and error are dependent do break the ideas, but a language can only hold the hands of poor developers so much. Someone determined enough to write bad code will do so in any language.

Realistically, if there is a handling problem, it is a problem for all values of all kinds. Every single problem one can point to about handling errors is also a problem when handing names, email addresses, random numbers, etc. To single it out as an error handling problem specifically is flawed.

> I have quite strong feelings on the subject that aren't fit for polite discussion.

I'd love to hear more. You won't hurt my feelings. Getting worked up about a programming language discussion is illogical.

Re: Show HN: Error return traces for Go, inspired by Zig

#85

Post by ForkMeOnTinder »

tuhats wrote: post #78
pixelpoet wrote: post #32

Earlier quoted context omitted.

It's mildly offensive that u10000 is a builtin type but vec2f is not (also note that I am not asking for general operator overloading!). Which has dedicated CPU instructions across all modern architectures, what's the relative usage frequency, what's the cost/benefit of each, etc etc... :( And we all know why u10000 is in there: because you have to have arbitrary-width integers when writing a compiler, so they figure…

> It's mildly offensive that u10000 is a builtin type but vec2f Zig does have builtin vec2f, it is spelt @Vector(2, f32).

@Vector is counterproductive for cases like vec2f, since it tries to force data into SIMD registers even when it would be more efficient to leave it in normal registers. In fact I've wondered in the past if Zig might end up slower than C for graphics code, if people misuse @Vector to get normal math operators back. For that reason I never use @Vector unless I already know what SIMD intrinsics I'd be writing in C.

Re: Show HN: Error return traces for Go, inspired by Zig

#86

Post by tialaramex »

randomdata wrote: post #84
lsaferite wrote: post #80

Earlier quoted context omitted.

> implicit restriction that if error is true, then the result is meaningless By 'implicit' I assume you mean 'by convention'? I say this because unless I've misread the go spec (and that's a distinct possibility), function returns are either a single value or a tuple and there is no specification on tuple returns and mutually exclusive values. FWIW, I mostly like go and work with it practically every day. I absolutel…

> I absolutely loathe it's ideas on error handling. Its idea is simply that error is just state like any other. I find that to be quite reasonable – and something I miss dearly when I work in other languages which try to get overly fancy to try and hide that fact. There is nothing special about errors. The machine certainly has no concept of errors. Why does it need special constructs? Bad practices like assuming T a…

> To single it out as an error handling problem specifically is flawed.

Sure, product types are the wrong shape for several different problems, not just error handling. Go doesn't have any other shape of user defined types so... too bad you're just stuck with something the wrong shape. Errors are an example where it's more obvious to more people.

Also the machine actually does know about errors, for example the x86-64 architecture defines several kinds of faults, for which provided handlers will be executed, Linux actually deliberately makes it impossible to run such fault handlers after any other way to reboot has proved ineffective, then trips a fault, because it knows an x86 CPU which can't run the fault handlers despite a fault will give up and reboot, which is what Linux was trying to achieve anyway. ARM has error interrupts, POWER has layers of nested error handling.

Re: Show HN: Error return traces for Go, inspired by Zig

#87

Post by randomdata »

tialaramex wrote: post #86
randomdata wrote: post #84

Earlier quoted context omitted.

> I absolutely loathe it's ideas on error handling. Its idea is simply that error is just state like any other. I find that to be quite reasonable – and something I miss dearly when I work in other languages which try to get overly fancy to try and hide that fact. There is nothing special about errors. The machine certainly has no concept of errors. Why does it need special constructs? Bad practices like assuming T a…

> To single it out as an error handling problem specifically is flawed. Sure, product types are the wrong shape for several different problems, not just error handling. Go doesn't have any other shape of user defined types so... too bad you're just stuck with something the wrong shape. Errors are an example where it's more obvious to more people. Also the machine actually does know about errors, for example the x86-6…

> product types are the wrong shape for several different problems

While that is true, the shape has no bearing on the handling problem. Go could have every type shape-defining feature ever conceived and it would still have the very same handling problem – for errors and everything else.

> Errors are an example where it's more obvious to more people.

In my experience, the vast majority of bugs I encounter in the real world are related to the handling problem of non-error values. That is where it is most obvious, and not just in Go. I expect errors only get talked about because it is fashionable to repeat what someone else said, not because anyone put any thought into it.

> Also the machine actually does know about error

Only within the confines of one human interpretation of how the machine functions, just as is the case for code. The machine itself has no such concept. It doesn't have awareness that a given state is an error or a rainbow.

Re: Show HN: Error return traces for Go, inspired by Zig

#88

Post by andy99 »

zoogeny wrote: post #36
pixelpoet wrote: post #15

(Aside about Zig, sorry. Although this applies to Go as well, I think?) Urgh I am so keen to switch to Zig but their attitude towards having vector operators just completely kills the viability for me as a graphics programmer. I've asked in their Discord, Andrew Kelley himself passed on commenting (I know his stance, every C++ dev wants their fav feature), but the reality remains that it's just infeasible to do with…

I was watching a recent talk about the new Mojo language [1]. There is a section on SIMD and how they treat scalar values as a special case of vector operations (around the 33 min time). It does seem that tensors are one of the core abstractions for modern ML systems. I've heard people joke that AI is just matrix multiplication. Python is such a flexible language that creating abstractions around its syntax was super…

  providing operators for linear algebra (and probably complex/quaternion) is a really important feature for any languages from this point in history going forward.
This is why I have started using Fortran for writing AI model inference code. It natively handles array manipulation like python and has a `matmul` intrinsic and compiles into fast code. There are some rough edges, but it's great as a low level matrix programming language which was its original point.

Re: Show HN: Error return traces for Go, inspired by Zig

#89

Post by prashantv »

da39a3ee wrote: post #77

I read the README but I'm not understanding yet why the return path might be what you want. The stack trace at error creation sounds more useful.

The stack trace and return path are pretty similar if the flow goes through function calls on a single goroutine, but if errors propagate across goroutines or across different stacks (E.g., via channels), then it can miss some useful details.

Here's an example that compares them: https://pkg.go.dev/braces.dev/errtrace#readme-comparison-wit...

Since the HTTP library uses a separate goroutine to create connections, the stack trace at creation time doesn't have details about the user request that triggered the connection.

Re: Show HN: Error return traces for Go, inspired by Zig

#90

Post by tubthumper8 »

healsdata wrote: post #55
Groxx wrote: post #44

Earlier quoted context omitted.

Well, sure, but by that metric this library is even easier to build yourself since it's only gathering a single stack entry per wrap. And it has no backwards compatibility to worry about. "You can build X by hand too" has little to do with why people choose to create or use libraries.

> "You can build X by hand too" has little to do with why people choose to create or use libraries. In my experience, "you can build X by hand" is the Go community's preferred approach.

It's been said that "Go" stands for "Go implement it yourself"
Post reply on HN