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

https://github.com/bracesdev/errtrace

by abhinavg • 3 years ago

133 75 3 years ago

github.com

Kharacternyk• 3 years ago

The logo is awesome. Has an artist been hired to create it?

abhinavg2• 3 years ago

Thanks! No, just one of the maintainers with a free evening.

Eun• 3 years ago

Can you explain why we should this over https://github.com/pkg/errors?

para_parolu• 3 years ago

Even this package is not needed anymore

dagss• 3 years ago

How do you get stack traces of errors?

abhinavg2• 3 years ago

The README covers the idea behind errtrace in more details, but the primary difference is in what is captured:

pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program.

errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site.

This gives you a different view of the code path: the stack trace is the path that led to the error, while the return trace is the path that the error took to get to the user.

The difference is significant because in Go, errors are just plain values that you can store in a struct, pass between goroutines etc. When the error passes to another goroutine, the stack trace from the original goroutine can become less useful in debugging the root cause of the error.

As an example, the Try it out section (https://github.com/bracesdev/errtrace/#try-it-out) in the README includes an example of a semi-realistic program comparing the stack trace and the return trace for the same failure.

avg_dev• 3 years ago

How does one go about implementing something like this? I am quite curious.

Groxx3• 3 years ago

At the very least:

This repository has been archived by the owner on Dec 1, 2021. It is now read-only.

It's largely complete so it is essentially fine at the moment, but it won't be adapted to future language or community changes. A future landmine.

oefrha2• 3 years ago

It’s archived mainly because it’s been superseded by fmt.Errorf() with the %w directive. Go 1.20 also introduced errors.Join() and multi-%w which github.com/pkg/errors lack, so using for green field projects is very ill-advised.

pixelpoet6• 3 years ago

(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 a DSL so it's just the wrong language for writing graphics code.

Night_Thastus3• 3 years ago

I'm a C++ dev, could you explain a bit of what is missing in Zig for vector operations? Does Zig not have operator overloading?

klyrs2• 3 years ago

Nope, no operator overloading. As I understand it, the philosophy is to not hide O(n) behavior behind notation that looks O(1).

truckerbill• 3 years ago

It is strange that we stop at scalars for algebra in most languages. Odin’s approach is almost more frustrating, allowing for quaternion types, but not clifford algebra which can elegantly describe them and much more(though i know it’s a comically niche request at this point in time)

reactordev• 3 years ago

agreed, further with today's parallelism it should be trivial but like you said, most languages stop at scalars and force the onus on you. I get it, higher order math is an implementation detail but to not provide the proper tools for those implementations is frustrating.

pixelpoet6• 3 years ago

The main thing that stands out about this comment to me (agreeing 100% about algebraic types) is the "at this point in time" bit, such boundless optimism :D

ForkMeOnTinder4• 3 years ago

That's one of the downsides of a BDFL. Zig is like 98% amazing, and 2% strange decisions that I think could have been avoided if the creator had more experience with languages other than C and Javascript.

I'm still a happy Zig user though, and hey, there's still time before 1.0.

pixelpoet6• 3 years ago

He's actually fluent in a lot of languages[0]. Just somehow apparently not much sympathy for numerical computing, or UI code (I'm fairly sure you want 2d vectors there too), or plotting, or ...

[0] https://andrewkelley.me/post/not-a-js-developer.html

dilyevsky3• 3 years ago

Not supporting operator overloading is not a “strange decision” it’s widely hated feature outside of very specific domains (like maths and graphics) and every shop i worked at which bothered with a c++ guideline banned it

zoogeny• 3 years ago

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 easy. I believe that was part of the reason Python has come to dominate this space (not the only reason obviously).

I too felt the same as you, but as a distant admirer of Zig. I totally understand that operator overloading can be misused. But I have an intuition that at least providing operators for linear algebra (and probably complex/quaternion) is a really important feature for any languages from this point in history going forward.

1. https://www.youtube.com/watch?v=SEwTjZvy8vw&ab_channel=LLVM

sevagh• 3 years ago

I've heard people joke that AI is just matrix multiplication

Not sure where the joke is, today's deep learning based AI models are literally matrix multiplications with learned weights.

xh-dude• 3 years ago

Julia has good ideas, interesting trade-offs here as well. ISTM the deep problem is that there’s so much room for optimization under composition of operations or with invariants not captured in types that the typical LinAlg library will never capture. But I agree most languages should be anticipating that users need something helpful here.

andy99• 3 years ago

  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.

lll-o-lll• 3 years ago

Doesn’t this open github issue imply that vector operators are still being considered? https://github.com/ziglang/zig/issues/7295

Or is it that the three years it’s been around indicate it will never progress?

pixelpoet6• 3 years ago

This is far better than my attempts at initiating the discussion, thanks for linking!

Also it seems like even the discussion of Geometric Algebra has been covered before 3 years ago: https://github.com/ziglang/zig/issues/7295#issuecomment-7389...

Unless it's actually possible after all this time (even in some random beta) to do vector code in infix notation, it doesn't feel like it's going to happen :(

el_oni• 3 years ago

Odinlang is a language in a similar space that seems to have first class support for matrix and vector operations. As well as having built in support for various graphics apps [0].

Seems like there is a bunch of interesting low level languages gaining steam at the moment.

[0] https://odin-lang.org/news/major-graphics-apis/

lenkite• 3 years ago

Does Odin have support for async/concurrency ?

crest• 3 years ago

Didn't Zig "just" decide to permanently stay irrelevant for performance critical code by replacing LLVM by a yet to be written home grown optimiser and code generator? Don't get me wrong LLVM has lots of warts, but the a good multi architecture optimiser and code generator is a larger project than the frontend and standard library for any reasonable language.

throwawaymaths4• 3 years ago

No. They are turning llvm into an "optional dependency", or plugin, or call it what you want. Day to day/debug compilation will be done with their own compiler and if you want you can cut a release with llvm to get all the optimizations when you're done, or at any time really.

Zig won't ship with llvm as part of the standard download, but i imagine it will be easy to get zig+llvm working

__loam• 3 years ago

Am I crazy or is there nothing stopping us from writing functions that work with vectors? I don't really understand why this is a big headache for graphics programming other than it not being your preferred syntax.

renox• 3 years ago

What's really sad is that not having overloading "ON" by default is a good idea, but it doesn't mean that language has to stop there, it's really simple to have a small language feature which would say that

a #everything_until_the_next_space b is rewritten in #everything_until_the_next_space(a,b)

So you'd have:

-a #foo b #foo c is foo(foo(a,b),c)

-a #foo b #bar c is forbidden, use parenthesis.

-and maybe #: for the inverse composition where a #:foo b #:foo c is foo(a, foo(b,c))

It's explicit, no hidden overloading, yet it's "short" enough to be usable: (a #* b) #+ c isn't that much worse than a*b+c and is much more readable than madd(mmul(a,b),c)..

If there is no implicit conversion name clashes shouldn't be too bad (both #+ could be usable for matrix and for graphic libraries).

Vanclief• 3 years ago

While from a first instance, this package seems a bit overkill, I think the idea is interesting and is something that can be improved for Go.

I also felt that Go errors where too bare-bones, so I developed a small package (https://github.com/Vanclief/ez) based on an awesome post that I saw here once. I use this package in all Golang code I touch.

zgk7iqea• 3 years ago

go is step by step reinventing exceptions

wwarner• 3 years ago

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

lsaferite2• 3 years ago

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.

alphazard• 3 years ago

Exceptions typically unwind the stack, producing a stack trace similar to what certain Go error types already do. Go's panic does actually unwind the stack. In a sense, Go has had Java/Python style exceptions, from the beginning, through panic and recover. This project distinguishes itself from that pattern in the README.

As far as error handling is concerned, errors as values is the modern thinking. Go is not behind the times here. If you squint, the `(T, error)` return type is very similar to Rust's `Result`, and the `if err != nil` idiom is basically Monadic control flow.

tialaramex3• 3 years ago

If you squint, the `(T, error)` return type is very similar to Rust's `Result`

This requires the kind of squinting where 9 x 9 = 81 is basically the same as 9 + 9 = 18 right? I mean, they're roughly the same symbols, albeit one at slightly different angle, and in a different order...

Result is a sum type, as are a lot of key things in Rust. Take the Rust type Result<bool,()> - this has three possible values, Ok(true), Ok(false), Err. The analogous Go product type has four possible values, (false,false) (false, true), (true, false) and (true, true).

stirante• 3 years ago

We actually did something similar in Go here: https://github.com/Bedrock-OSS/go-burrito

I guess the difference we try to make is that we really wanted to make errors that are understandable by users. Each time the error is returned we try to wrap it with an information where and why.

da39a3ee• 3 years ago

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.

prashantv• 3 years ago

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.

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

Related Stories