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

21–30 of 92 posts

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

#21

Post by oefrha »

Groxx wrote: post #11
oefrha wrote: post #9

Earlier quoted context omitted.

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.

Except for the stack trace part, which is a gigantic reason why it was popular. tbh I'm not sure what the current popular option is for wrapping with stack traces. Re join: it isn't a joiner-error, it has no need to do anything for that. Just stdlib-join-then-wrap.

It’s pretty easy to write your own Errorf() wrapper or some sort of WithStack() that stores runtime/debug.Stack() output. github.com/pkg/errors offers more flexibility in formatting though.

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

#22

Post by Night_Thastus »

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'm a C++ dev, could you explain a bit of what is missing in Zig for vector operations? Does Zig not have operator overloading?

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

#23

Post by truckerbill »

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…

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)

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

#24

Post by klyrs »

Night_Thastus wrote: post #22
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'm a C++ dev, could you explain a bit of what is missing in Zig for vector operations? Does Zig not have operator overloading?

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

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

#25

Post by Night_Thastus »

klyrs wrote: post #24
Night_Thastus wrote: post #22

Earlier quoted context omitted.

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?

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

Strange.

How is that different from say, a function call? A function may look like a single O(1) operation from the input/output/name, but actually do something much more complex. That seems like the same thing to me, and very common. (and frankly I'm not sure that could even be avoided)

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

#26

Post by ForkMeOnTinder »

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…

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.

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

#27

Post by [deleted] »

truckerbill wrote: post #23
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…

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)

[deleted]

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

#28

Post by mordechai9000 »

riku_iki wrote: post #12
packetlost wrote: post #10

Earlier quoted context omitted.

Exceptions are only better than C style error return numbers but worse than pretty much every other model of error handling we have today.

There is an opposite opinion on this

I just picked up Go and thought I might use it for Advent of Code, to help gain some familiarity. The error handling kind of threw me off, though. I am coming from typescript most recently, and I think crashing on unhandled errors is a good thing. I have bad memories of perl doing unintended things after failing to catch an error.

But I am willing to go out of my comfort zone. I think I'll probably have to find some linter configuration that will squawk when an error is ignored, though. Just for my own sanity.

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

#29

Post by klyrs »

Night_Thastus wrote: post #25
klyrs wrote: post #24

Earlier quoted context omitted.

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

Strange. How is that different from say, a function call? A function may look like a single O(1) operation from the input/output/name, but actually do something much more complex. That seems like the same thing to me, and very common. (and frankly I'm not sure that could even be avoided)

I didn't mean to volunteer to defend this choice, but without investigating a function you can't really support an opinion about its runtime. A language can make such promises about its basic syntax however.

Perhaps I'll rephrase how I understand the philosophy: if it's a function call, it should look like a function call. Operator overloading breaks that.

That said, this isn't my hill to die on.

Edit to clarify my final sentence there: I have zero interest in debating this any further. Pixelpoet, if you're going to be so fussy, go read Harvey and van der Hoeven and stop trying to win language fights, they're tedious.

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

#30

Post by ForkMeOnTinder »

klyrs wrote: post #24
Night_Thastus wrote: post #22

Earlier quoted context omitted.

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?

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

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;
  }
Post reply on HN