Show HN: Error return traces for Go, inspired by Zig • Hacker News Board

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

#71

Post by [deleted] » Thu, Nov 30, 2023, 2:38 AM UTC

tialaramex wrote: post #70

dilyevsky wrote: post #49

Earlier quoted context omitted.

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

C++ operator overloading gets banned because C++ programmers invariably abuse it and cause problems, even the standards committee can't help themselves, which is how I/O Streams are a standard library feature. C++ also allows you to overload short-circuiting operators, but of course your overload can't short-circuit so you just silently destroyed an important feature. Why ? As others have pointed out, several languag…

[deleted]

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

#72

Post by dilyevsky » Thu, Nov 30, 2023, 2:42 AM UTC

tester756 wrote: post #65

dilyevsky wrote: post #49

Earlier quoted context omitted.

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

You guys are "interesting" in this c++ world C# has operator overloading and during my whole career I have never seen it abused so hard that people needed to ban it, let alone write guidelines and a lot of shops adopting it. I barely see anyone use it not for really good cases like graphics. The only interesting case was using "/" operator for Path Combines so "home" / "folder1" performs Path.Combine("home", "folder1…

I think it’s mainly c++ devs are very performance sensitive (why else would you subject yourself to this torture?) so they hate it when your ‘+’ is suddenly O(n^2) and with side-effects

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

#73

Post by stirante » Thu, Nov 30, 2023, 2:55 AM UTC

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.

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

#74

Post by throwawaymaths » Thu, Nov 30, 2023, 3:10 AM UTC

tialaramex wrote: post #70

dilyevsky wrote: post #49

Earlier quoted context omitted.

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

C++ operator overloading gets banned because C++ programmers invariably abuse it and cause problems, even the standards committee can't help themselves, which is how I/O Streams are a standard library feature. C++ also allows you to overload short-circuiting operators, but of course your overload can't short-circuit so you just silently destroyed an important feature. Why ? As others have pointed out, several languag…

> even the standards committee can't help themselves

cout << "foo" << endl;

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

#75

Post by Night_Thastus » Thu, Nov 30, 2023, 5:12 AM UTC

pixelpoet wrote: post #40

klyrs wrote: post #29

Earlier quoted context omitted.

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 f…

I appreciate your being such a good devil's advocate, however as ForkMeOnTinder points out, there is already the super complicated[0] overloaded O(N^1.58+) operator for arbitrary precision integer multiplication, easily argued to be vanishingly less useful than simple vector operators, particularly if they were well-expressed at the IR level and well-mapped to modern hardware / instructions. The ask isn't for general…

To me it does seem a weird hill to die on. If I'm using an operator on a non-primitive/non-trivial type - I'm going to consider the possibility that it does something more complex. It would be strange not to.

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

#76

Post by randomdata » Thu, Nov 30, 2023, 5:24 AM UTC

bensecure wrote: post #69

tialaramex wrote: post #67

Earlier quoted context omitted.

> 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 - this has three possible values, Ok(true), Ok(fa…

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.

That depends on perspective.

An idiomatic Go function will ensure that T is always useful, regardless of the error state. At very least it will return the zero value for T, to which the Go maxim states: Make the zero value useful. From the perspective of writing the function returning (T, error), there will always be four states, with T and error being independent of each other. Anything else is faulty design.

Unfortunately, some early Go code written before things were well understood left T to be undefined given certain error states, so one cannot assume that T will be valid in all cases for all functions. This does mean that the caller's perspective can only reliably consider three states absent of diving deeper (e.g. reading the documentation).

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

#77

Post by da39a3ee » Thu, Nov 30, 2023, 10:55 AM UTC

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.

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

#78

Post by tuhats » Thu, Nov 30, 2023, 12:43 PM UTC

pixelpoet wrote: post #32

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; }

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).

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

#79

Post by lenkite » Thu, Nov 30, 2023, 1:24 PM UTC

el_oni wrote: post #53

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…

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/

Does Odin have support for async/concurrency ?

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

#80

Post by lsaferite » Thu, Nov 30, 2023, 2:05 PM UTC

bensecure wrote: post #69

tialaramex wrote: post #67

Earlier quoted context omitted.

> 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 - this has three possible values, Ok(true), Ok(fa…

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 absolutely loathe it's ideas on error handling. I have quite strong feelings on the subject that aren't fit for polite discussion.