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

Why Generics?

blog.golang.org

Post reply on HN
Print view View original

91–100 of 261 posts

Re: Why Generics?

#91

Post by snazz »

goatlover wrote: post #72
tylerflick wrote: post #68

Earlier quoted context omitted.

This. If I really need generics I'll use a different language.

Must every popular language evolve into C++ or Common Lisp?

I wonder if there's room for a language that is small, allows for nearly limitless abstraction, and still has great tooling. Go is (or, you could argue, was) small, and now has better tooling, but is just beginning to increase its ability to create abstractions. Common Lisp is large (only 200 pages fewer in its spec than C++, if I remember correctly), has unparalleled tooling (like the don't-unwind-the-stack debugging and SLIME), and really good abstraction power. Scheme is small and consistent (unlike CL), and also can create similarly advanced abstractions, but is missing some of the tooling that CL has enjoyed for eons.

I'll be really cool to see a language that feels consistent, tight, well-engineered, and small; can create powerful abstractions similar to what can be achieved using CL macros and CLOS; and has an awesome debugger, editor interop, interactive programming with a REPL, build tools, etc.

Re: Why Generics?

#92

Post by theshrike79 »

takeda wrote: post #71
tylerflick wrote: post #68

Earlier quoted context omitted.

This. If I really need generics I'll use a different language.

This reminds me the discussion about first version of iPhone how so many people were advocating why adding copy&paste functionality was a bad idea.

More like people were advocating against the shitty Copy&Paste phones used to have.

When it came out, it was possible to C&P pictures to emails and other fancy stuff that wasn't possible before.

Re: Why Generics?

#93

Post by dalksfjid »

weberc2 wrote: post #85
iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

It seems like you’re objecting to the messaging (not referencing an existing language, which doesn’t work for people not familiar with the implementation of that language) and also that, at its inception, Go didn’t pick (randomly?) a language off of which to model its generic implementation. Am I misreading?

>objecting

Reads more like suggesting to me. And, a helpful one.

Re: Why Generics?

#94

Post by weberc2 »

jknoepfler wrote: post #88

The decision to overload parentheses to express generic type is the only part of this spec I find nauseating. It doesn't scan well, and doesn't have a precedent in any major generic implementation I'm aware of. <, [, @-annotation... I don't care. Just don't mush it into the function declaration with the same syntax that encloses parameter.

Agreed, specifically it creates ambiguities in parsing (for computers but worse: for humans). Given Foo(x), you can’t tell if it’s a function call or a generic type without knowing what x refers to. You need context from afar to disambiguate.

Re: Why Generics?

#95

Post by Vendan »

mikeash wrote: post #82
AceJohnny2 wrote: post #52

Earlier quoted context omitted.

> To those Go programmers who think they will never use them - it’s worth a little learning, and once you do you will find more ways to use them to make your code more applicable. There was a story I came across once. It went something like this: The proponents of every gizmo think their gizmo is superior to the others, because it's got these useful features that the others lack, and isn't encumbered by the weird use…

This is the Blub Paradox. http://wiki.c2.com/?BlubParadox

What is it when you know about the power of features of the "higher level" languages, like generics, but still chose the "blub language" because of other reasons, like ease of hiring devs?

Re: Why Generics?

#96

Post by iainmerrick »

weberc2 wrote: post #85
iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

It seems like you’re objecting to the messaging (not referencing an existing language, which doesn’t work for people not familiar with the implementation of that language) and also that, at its inception, Go didn’t pick (randomly?) a language off of which to model its generic implementation. Am I misreading?

Well, there doesn’t seem to be a lot of discussion of alternatives at all, so I can’t really see what design and implementation decisions are actually being made. Most likely I’m just looking in the wrong place, and those discussions are taking place elsewhere.

I guess my complaint is that this talk, like all the other updates on their progress on generics, implies that Go generics exist in a vacuum, whereas in reality there’s a ton of prior art that could usefully be referenced.

Edit to add: this particular talk is focused on syntax details. Those aren’t unimportant but they’re a small part of the whole picture. As I commented on the detailed Contracts proposal, the decision to add contracts rather than simply using interfaces (as in Java and C#) seems significant but isn’t explained.

Re: Why Generics?

#97

Post by icholy »

dimgl wrote: post #7
mlevental wrote: post #4

why are people obsessed with simplicity? there's a quotation my Einstein that I like to keep in mind: "make things as simple as they can be but no simpler". the implication being that if you make things too simple then you actually break things. lack of generics makes for software that's actually more complex than it needs to be. Take for example Swift: lots of complex features (protocols, all manner of functional tr…

I have yet to find one practical application for generics in the apps I've built in Go.

You've never used a data-structure other than the built in maps and slices?

Re: Why Generics?

#98

Post by aczerepinski »

Mixed feelings about this. One of my favorite things about Go is that it's a small and relatively simple language. It's a "fast enough" language without the steep learning curve of Rust. Too many features that make sense individually could change the calculus to "might as well use Rust".

Re: Why Generics?

#99

Post by jsgo »

Generics with Reflection was the first gut check I experienced while working after completing college and getting an ASP.NET job. Like 2-3 weeks into said job.

Had to do an application that dealt with 4-5 forms (can't remember). Like 300 fields on the bigger ones, smaller ones 50ish. I started out on one that was mid-200. I'm coding the way I was taught in school: object set object properties based on txtWhatever.Text. Like 240ish times. I can't remember how many lines of code were in this code behind, but it was substantial.

I turn it in, it works. Go me, let me go on to the next one. The senior guy on the team does one of the smaller forms. But he uses generics and reflection to basically iterate over all of the fields on the form and sets them to the ephemeral properties on this generic object in like 8-9 lines of code. Then there was the rendering code that was vaguely similar.

Added bonus: 99% of his code behind could be copy and pasted over to the newer forms and handle all of the work related to getting/setting form values. After the code proved to work for a few weeks, replaced the massive code behind with call to his code (passing in the form object and the generic to be set and used later) with the same result and one area to manage code and it isn't an insanely large code behind file (got better with not one filing everything in time too).

Not saying generics and/or reflection are a silver bullet (I don't feel they are. Rarely so do they end up being the thing I go for), but it was definitely eye opening that straying from "see spot run" code could be advantageous. And that I wasn't "good to go" already.

Re: Why Generics?

#100

Post by monkeyfacebag »

013a wrote: post #76

The proposed syntax feels like a caricature to me. That something like this could be easily possible: func (c Connection) Read(type T Writeable)(into *T) (int, error) { This is quite securely inside shark-jumping territory. Also; I haven't seen Rob Pike's name really anywhere in these blog posts or discussions, or on any recent Go blog entry. Is he still involved with the Go project day-to-day? I always got the impre…

As far as I can tell, the latest proposal draft forbids type parameterized methods. One must admit the type parameter to the receiver or define a type parameterized function. I am making no claims about your broader point, only clarifying that your example is not permitted by the proposal draft. See https://go.googlesource.com/proposal/+/4a54a00950b56dd009648...
Post reply on HN