Maybe adding generics to Go is about syntax after all • Hacker News Board

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

#21

Post by AnaniasAnanas » Tue, Sep 04, 2018, 3:32 PM UTC

evmar wrote: post #15

gnulinux wrote: post #6

Earlier quoted context omitted.

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…

I tinkered a bit (as many others have too!) with a lisp syntax for C, just to see what it'd feel like. That is, exact C semantics (so not inventing anything) but sexpressions. What I remember struggling with is that it was surprisingly kind of hard to remember when parens are necessary where. For example you might define an if statement: (if (> x 3) (printf ...)) Looks nice, but what about if you want multiple things…

Or "if" could be a special form so that you can just write (if (> x 3) (printf a) (printf b))

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

#22

Post by oblio » Tue, Sep 04, 2018, 3:33 PM UTC

gnulinux wrote: post #6

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…

The average programmers seem to like different symbols for what they consider different things. I don't know if it is better or not, but it seems to be the status quo...

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

#23

Post by AnaniasAnanas » Tue, Sep 04, 2018, 3:33 PM UTC

jclulow wrote: post #14

gnulinux wrote: post #6

Earlier quoted context omitted.

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…

Because not everyone agrees (thankfully!) that syntax is uninteresting or irrelevant, or that Lisp is some amazing global aesthetic or ergonomic maximum.

Why thankfully?

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

#24

Post by pjc50 » Tue, Sep 04, 2018, 3:36 PM UTC

gnulinux wrote: post #6

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…

The ""market"" (including me) overwhelmingly prefers Algol-derived languages. The different types of bracket used in different ways seem to be a benefit. Very few empirical studies of this have been done, and there's also the problem that "easy to read (for newbies)" and "easiest to read (for experienced people familiar with C syntax)" can be completely different.

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

#25

Post by Someone » Tue, Sep 04, 2018, 3:43 PM UTC

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.

No, it isn’t, not even within a single file. https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html:

”If you write a program which generates source code, such as the bison parser generator, you may want to adjust the preprocessor’s notion of the current file name and line number by hand.

[…]

#line linenum

linenum is a non-negative decimal integer constant. It specifies the line number which should be reported for the following line of input. Subsequent lines are counted from linenum.

#line linenum filename

linenum is the same as for the first form, and has the same effect. In addition, filename is a string constant. The following line and all subsequent lines are reported to come from the file it specifies, until something else happens to change that. filename is interpreted according to the normal rules for a string constant: backslash escapes are interpreted. This is different from ‘#include’.”

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

#26

Post by pjmlp » Tue, Sep 04, 2018, 3:43 PM UTC

dagss wrote: post #12

jonathankoren wrote: post #7

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.

Go has a lot of pain points but the one positive thing it has over other languages is how it handles interfaces. The whole point is that the caller can make new interfaces to fit existing structs in other libraries.

Nothing new, ML derived languages also allow for it.

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

#27

Post by danharaj » Tue, Sep 04, 2018, 3:57 PM UTC

wbl wrote: post #20

Why not adopt standard ML's polymorphism semantics? Is there some type theory issue I don't know about preventing that?

I don't know much about Go. Does it have subtyping? Mixing polymorphism and subtyping isn't obvious. Stephen Dolan's thesis on algebraic subtyping [0] is the first really satisfactory answer, all previous ones having significant drawbacks, but it's only 2 years old, untested in a production language.

Considering how conservative, bordering on reactionary, the philosophy of Go seems, I think it's politically untenable.

[0] PDF: https://www.cl.cam.ac.uk/~sd601/thesis.pdf

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

#28

Post by k__ » Tue, Sep 04, 2018, 3:59 PM UTC

pjmlp wrote: post #26

dagss wrote: post #12

Earlier quoted context omitted.

Go has a lot of pain points but the one positive thing it has over other languages is how it handles interfaces. The whole point is that the caller can make new interfaces to fit existing structs in other libraries.

Nothing new, ML derived languages also allow for it.

TypeScript too.

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

#29

Post by [deleted] » Tue, Sep 04, 2018, 4:06 PM UTC

cyphar wrote: post #11

jonathankoren wrote: post #7

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.

Actually one of the main benefits of Go over Java is the lack of a requirement for "implements" because otherwise it means that you cannot use a type in a context where the original developer did not intend it to be used (though I imagine you're implying that it would not be required). However quite a few Go developers now use interfaces with an unexported method specifically to stop users from misusing their types i…

[deleted]

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

#30

Post by cyphar » Tue, Sep 04, 2018, 4:07 PM UTC

ainar-g wrote: post #18

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…

Yeah. I always try to include some context with my errors, so the only actual uses for check/handle I have is handle err { log.Fatal(err) } in quick "scripts". And even there I should probably provide more context. All clean-up work is already done in defer. Overall, check/handle feels like a poorly-thought slap-on to me, on par with ON-units from PL/I[1]. And PL/I is not something you want as an inspiration. [1] htt…

Right -- people already use defer as a way of mapping errors and doing cleanup in an already awful way:

    func something() (Err error) {
        defer func() {
            if Err != nil {
                someCleanup()
                Err = fmt.Errorf("wrapping: %v", Err)
            }
        }()
        return blah()
    }

And unlike handle you can actually give an arbitrary mapping function, while as far as I can tell you'd need to do something like

    handle err { return mapError(err) }

Rather than the more ergonomic

    handle mapError

Or

    handle func(err Error) { return mapError(err) }

But whatever -- all of this is pretty useless. The main benefit of check in my mind is actually that you would be able to easily bump your test coverage -- because Go test coverage is based on lines and so the repeated use of

    if err != nil {
        return err
    }

artificially dilutes your test coverage (you don't need to test that every error is propagated -- that's just doesn't make any sense and might not be possible if you are returning directly from os.* functions that don't even have fault-injection).