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

51–60 of 92 posts

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

#51

Post by snovv_crash »

dilyevsky wrote: post #49
ForkMeOnTinder wrote: post #26

Earlier quoted context omitted.

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.

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

Banned for in-house use, sure. Require an extra review before including a library, sure. But don't tell me you refuse to use Eigen and force everyone to write their own matrix multiplication routines that don't have operator overloading...

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

#52

Post by pixelpoet »

lll-o-lll wrote: post #39
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…

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?

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 :(

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

#53

Post by el_oni »

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/

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

#54

Post by dilyevsky »

snovv_crash wrote: post #51
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

Banned for in-house use, sure. Require an extra review before including a library, sure. But don't tell me you refuse to use Eigen and force everyone to write their own matrix multiplication routines that don't have operator overloading...

That is why I specifically mentioned math and graphics as exceptions. Honestly I still like explicit DSL model better for these than trying to build dsl on top of your existing language c++/lisp style

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

#55

Post by healsdata »

Groxx wrote: post #44
oefrha wrote: post #21

Earlier quoted context omitted.

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.

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.

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

#57

Post by bsder »

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 is not

u10000 exists only because we want u3, u7, and u13 as builtin types.

u3, u7, and u13 are useful for embedded and systems programming.

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

#59

Post by alphazard »

zgk7iqea wrote: post #56

go is step by step reinventing exceptions

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.

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

#60

Post by crest »

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…

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