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

Maybe adding generics to Go is about syntax after all

dave.cheney.net

Post reply on HN
Print view View original

1–10 of 92 posts

Re: Maybe adding generics to Go is about syntax after all

#2

Post by cyphar »

On the topic of "syntax is important" (though not related to generics -- other than by aside to the Result type) I'm still not a huge fan of the handle syntax -- I reckon something more similar to Rust's .map_err() would be handled better because lots of people now use pkg/errors[1] which has the boilerplate of

    if err != nil {
        return errors.Wrap(err, "some message that is unique to this line")
    }
and the handle construct doesn't really handle (excuse the pun) this properly (you have to re-define handle each time or have a local variable or something similar). Which means that the new construct won't actually be massively helpful unless the only thing you want to do is errors.WithStack or just bubble the error back up.

But I do get why they couldn't get .map_err() -- because that's something you can only really do if you have a Result type.

[1]: https://github.com/pkg/errors

Re: Maybe adding generics to Go is about syntax after all

#5

Post by foolfoolz »

i haven’t written a whole lot of go, but from what i’ve done and what i see coming in go 2 i don’t really want to have to write a lot more. go felt like it was modern-vintage to start with memory management but also values/pointers. with a heavy emphasis on multi return error handling instead of generics (Either), nil instead of Option, and mutability by default

and the future seems to be more weirdness. magic methods like handle. list comprehensions still uncertain. contracts sound like a backwards compatible break and duplicate of existing functionality.

i used go to use libraries and low memory foot print for my small projects. but i bet there’s simpler routes out there

Re: Maybe adding generics to Go is about syntax after all

#6

Post by gnulinux »

fithisux wrote: post #3

Why not reuse Common Lisp macros?

Why not use lisp syntax, at all? Why do we have to reinvent syntax every single generation? I'm not an old school engineer (I'm in my early 20s and in my first job, freshly outta college) but I can't see why we don't use lisp, prolog or ML syntax for everything. Seems vastly better than C-like synaxes in all ways I can think of, easier to implement, easier to extend, easier to read (imho) etc... When I program even in a low caliber lisp like elisp (which I do routinely since I use emacs) it feels like syntax gets in my way less frequently compared to python, C, Javascript etc... I just wanna think about my program, and not the syntax. If lisp is not expressive enough, why not just ML? Why do we have to reinvent it so many times when syntax is not an interesting or relevant problem (e.g. Rust syntax)?

Re: Maybe adding generics to Go is about syntax after all

#7

Post by jonathankoren »

If Go gets generics, maybe they’ll actually add an ‘implements’ keyword for interfaces and no more of this:

  var _ SomeIface = SomeConcrete{}
  var _ AnotherIface = SomeConcrete{}
Just to see if you actually implemented all the signatures on the interface correctly.

Re: Maybe adding generics to Go is about syntax after all

#8

Post by ape4 »

cyphar wrote: post #2

On the topic of "syntax is important" (though not related to generics -- other than by aside to the Result type) I'm still not a huge fan of the handle syntax -- I reckon something more similar to Rust's .map_err() would be handled better because lots of people now use pkg/errors[1] which has the boilerplate of if err != nil { return errors.Wrap(err, "some message that is unique to this line") } and the handle constr…

C/C++ __LINE__ is unique to a line.

Re: Maybe adding generics to Go is about syntax after all

#9

Post by cyphar »

ape4 wrote: post #8
cyphar wrote: post #2

On the topic of "syntax is important" (though not related to generics -- other than by aside to the Result type) I'm still not a huge fan of the handle syntax -- I reckon something more similar to Rust's .map_err() would be handled better because lots of people now use pkg/errors[1] which has the boilerplate of if err != nil { return errors.Wrap(err, "some message that is unique to this line") } and the handle constr…

C/C++ __LINE__ is unique to a line.

I'm not sure you understand what I mean -- the "unique to a line" message is actually a descriptive message not a line number. errors.WithStack gives you the file, line, and function name for free and works with handle -- my complaint is that giving descriptive and stacked error messages will be very hard with handle (but is not fundamentally hard with Rust's map_err even though their error packages aren't as well-developed as Go's from my experience).
Post reply on HN