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

71–80 of 92 posts

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

#71

Post by AnimalMuppet »

dragonwriter wrote: post #65
AnimalMuppet wrote: post #63

Earlier quoted context omitted.

I think it's going to be really hard to do the study in a rigorous way. Solid data would be nice, though. Then we could stop guessing. My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Now it's on the fringe. I assert that people had been exposed to Lisp, it was widely used. It became less and less popular. It's not that industry didn't know Lisp; they knew it and turned away from…

> My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Unlikely, given that TIOBE the company wasn't founded until 2000, and the TIOBE index is based on web search engine results, and there weren't any web search engines, or a web for them to search, in the 1980s.

https://www.tiobe.com/tiobe-index/ has historical data going back to 1988. (Presumably they used a different methodology for the older data.)

But I remembered wrong. They list Lisp as #2 in 1988.

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

#72

Post by stouset »

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.

Implicit implementation of interfaces is a disjoint concept from allowing third-party users to implement new interfaces on first-party or second-party structs.

The latter is wonderful, and other languages support this without needing to resort to the former.

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

#73

Post by [deleted] »

ilovecaching wrote: post #66
oppositelock wrote: post #62

Earlier quoted context omitted.

I've also been writing a lot of Go professionally for a long time, and I've used every part of the language extensively, and I disagree. There are many times I remember where I've had to implement some sort of application specific data structure that's not built into the language, and generics would have made it a lot nicer. I made it generic by using interfaces, but then you have the problem of throwing away type sa…

What do you mean by nicer? I would imagine that something that is application specific would not require generics. Interfaces do not throw away type safety if they are used correctly. They are also better suited for the consumer of the type rather than the definer. One of your problems might be that you are prematurely abstracting your interfaces for your callers.

[deleted]

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

#74

Post by [deleted] »

ilovecaching wrote: post #45
artursapek wrote: post #38

I was at Gophercon and saw Russ's video where he spent 30 seconds explaining what generics were to the audience and showed a half-baked example of the syntax they are considering. I've been using Go for almost 5 years now and have no desire to see generics introduced. It would ruin what is currently a very simple and easy-to-use language. Am I the only one who is hoping this whole thing fizzles out?

Yes, the people who want generics are either people who don't use Go, or don't understand the purpose of Go and the implications of adding them to the language.

[deleted]

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

#75

Post by ljm »

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…

I enjoy the Go authors' attempts to propose novel or innovative solutions to existing problems, without going straight towards the status quo, but I do wonder if sometimes they're trying too hard.

At risk of cargo culting or not knowing enough about the problem space, I can only think of what I've recently read from The Psychology of Computer Programming^0. The entire reason that generics and error handling are difficult is because of the decision to avoid a syntax table.

This to me feels like an artificial constraint because the Go authors are optimising for compiler simplicity and not developer ergonomics. So the developer has to parse a whole lot more because the compiler guys don't want to take a hit. The reason why generics are such a pain in the ass, and errors are such a pain in the ass, is because the emotional attachment to how Go currently runs and what it stands for is still far more powerful than any attempt to innovate on the language's own status quo.

So what Cheney says makes some sense in that in a lot of ways, it feels more intuitive than implementing language grammar that isn't executed but looks like real code. But at the same time, the whole debate is basically around how to change go without changing it.

Either do it or don't.

[0]https://leanpub.com/thepsychologyofcomputerprogramming

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

#76

Post by AnimalMuppet »

taeric wrote: post #67
AnimalMuppet wrote: post #63

Earlier quoted context omitted.

I think it's going to be really hard to do the study in a rigorous way. Solid data would be nice, though. Then we could stop guessing. My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Now it's on the fringe. I assert that people had been exposed to Lisp, it was widely used. It became less and less popular. It's not that industry didn't know Lisp; they knew it and turned away from…

Agreed it would be really hard. I do want to underscore I'm interested in the question. And I don't know which way I expect it to go. My personal hunch is that lisp was just too expensive when most industry took off. In near every way. C compilers being basically free is a ridiculous advantage. Yes, there are free lisp implementations today. However, early mover advantage is working against them, now.

I'd agree that Lisp was too expensive when things took off. Not just in terms of compilers, but also in terms of hardware requirements. C was a better match for the tight memory of the day.

My personal hunch about the experiment (based on nothing more than my intuition) is that people think differently, and that Lisp's syntax is a good match for how some people think, but not for how the majority of programmers think. But as I said, that's just my current intuition. My intuition a year ago, for example, was different...

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

#77

Post by slavapestov »

djur wrote: post #17
dagss wrote: post #13

Earlier quoted context omitted.

...except that both can be applied to solve the same problems. And so they are in fact very related. For instance with a macro you could do (made up syntax) SortIntSlice = mymacros.MakeSorter!(int) ...then at compile time have code for sorting a slice of ints generated. This is again similar to C++ templates (main difference is C++ will implicitly instantiate instead of explicitly). And C++ doesn't need generocs beca…

Using macros to implement generics has the same problem that C++ templates have, which is described in the Go 2 generics proposal: it's difficult to provide clear error messages for developers in many cases. Functions parameterized on a single type are the easy problem to solve. Where things get thorny is when you parameterize on multiple types with various constraints and/or have some kind of interaction in the func…

Macros and C++ templates are also incompatible with separate compilation which leads to increased compile times and binary bloat.

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

#78

Post by atombender »

danharaj wrote: post #27
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…

Go does not have subtyping. Its type system is sufficiently rudimentary that steering it towards ML would just be just too extreme at this point.

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

#79

Post by goatlover »

oblio wrote: post #22
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…

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

But if that's really the case, then why hasn't Perl way of denoting the basic kind of variable with a starting symbol been copied in other languages?

My guess is because most languages don't do that, so people are used to variables not having a symbol denoting their basic type. It largely comes down to what sort of syntax people are accustomed to.

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

#80

Post by slavapestov »

cyphar wrote: post #40
pdeuchler wrote: post #37

Earlier quoted context omitted.

As someone who just went to gophercon I'm still confused why they're tackling error handling first, and then generics. I would imagine tackling errors in Go 2.1 with the help of generics would make for a much much cleaner solution... if we even need one (i'm not fully convinced verbose error checking is as bad as people say it is)

(I agree that waiting until generics were ironed out would have been a better idea, because we already have pretty large communities around existing error handling libraries. Unfortunately this is a pattern of the Go language designers -- they have often ignored community consensus around an issue, like they did with vendor/ and other similar issues). My main issue with it (aside from making memes about RSI) is that…

The problem you describe is not specific to Go. You should always test all error paths in production code. Using mocks or error injection can help with triggering otherwise “impossible” cases.
Post reply on HN