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

Go 1.18

go.dev

Post reply on HN
Print view View original

181–190 of 614 posts

Re: Go 1.18

#181

Post by HideousKojima »

gnoack wrote: post #175

The general excitement about generics on this thread makes me uneasy. Please keep in mind that generics are a pretty big hammer - they can add a lot of complication if not used with caution. Only use a language feature if you absolutely must.

I see it the other way around, generics reduce complication and allow for code that's a lot more elegant and simple than without. It definitely adds complexity on the compiler side of things, but using them in C#, TypeScript, and Java has been only a plus. Unless you count that time I tried to do stuff with generic interfaces in Entity Framework Core, but that was EF Core's fault as opposed to generics's.

Re: Go 1.18

#183

Post by HideousKojima »

flippinburgers wrote: post #179

Honestly I think this will make the overall programming experience worse.

In what way? Almost every other major language has them without major issues.

Go devs saying generics are a bad thing reminds me of people in Oregon freaking out over being allowed to pump their own gas while the other 49 states have been doing that for decades.

Re: Go 1.18

#184

Post by chabad360 »

haolez wrote: post #144

I hope open source Go code in the wild remains easy to read and understand. Generics look cool, despite this possible downside.

I've found generic code much easier to read once I started playing with it myself. It might be worth implementing a generic sorter (or some other easily generic construct) just to get more familiar with the new syntax.

Re: Go 1.18

#185

Post by stouset »

keybored wrote: post #107
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

This comment has the tone of being genuinely inquisitive, yet it mostly comes up with negative and depraved reasons for as to why someone one might dislike $lang. - Rational reasons (frustrations with the language design) are briefly acknowledged but then some reason left by the wayside - It is suggested that people don't have principled objections to $lang; they will "latch onto" something else if $misfeature is fix…

This needs to be higher up, and summarizes my main cultural oppositions to golang. I'll also add:

- Extensive laundry lists of frustrations, sharp edges, antipatterns, and ways the language makes it trivial to write incorrect code are dismissed as nits or minor annoyances.

- Missing features that have no way of being worked around are dismissed off-hand as unnecessary complexity.

- The language authors repeatedly ignore mistakes learned from other language projects and rush headlong right back into them, with predictable consequences.

- Verbosity is mistaken for "simplicity" while bugs scaling roughly linearly with lines of code is quite literally one of the few reliable bits of data we actually have in this industry.

Re: Go 1.18

#186

Post by wtfishackernews »

Mawr wrote: post #176
frenchie4111 wrote: post #139

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional

type Optional[T any] struct { value *T } Don't use a pointer - it's bad for performance. func MakeOptional[T any](value *T) Optional[T] { Use `New` instead - it's the idiomatic name for a constructor in Go. Drop the `Optional` part - the module name suffices - the caller will see: `opt.New`. Personally I just call the module `optional`, I think it's clearer: `optional.New`. func (o* Optional[T]) Unwrap() (T, error) {…

For json marshalling, I would defer to the underlying type's marshalling if it's present, and return `null` otherwise.

Re: Go 1.18

#187

Post by oconnor663 »

kaba0 wrote: post #166
oconnor663 wrote: post #114

Earlier quoted context omitted.

> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? I coded primarily in Go at work for several years, although that was several years ago. I understand that package management and now generics have changed in major ways since then. But at the risk of being out of date, here are some language-level complain…

And the stupidest of all: defer is function-scoped, not block.

I don't like calling any of these things stupid. They're tradeoffs, and I can respect why they were made.

Re: Go 1.18

#188

Post by tptacek »

HideousKojima wrote: post #181
gnoack wrote: post #175

The general excitement about generics on this thread makes me uneasy. Please keep in mind that generics are a pretty big hammer - they can add a lot of complication if not used with caution. Only use a language feature if you absolutely must.

I see it the other way around, generics reduce complication and allow for code that's a lot more elegant and simple than without. It definitely adds complexity on the compiler side of things, but using them in C#, TypeScript, and Java has been only a plus. Unless you count that time I tried to do stuff with generic interfaces in Entity Framework Core, but that was EF Core's fault as opposed to generics's.

As with everything else, sometimes this is true, sometimes it isn't. In languages with pervasive generics, figuring out how things work can mean following several extraneous layers of indirection as any opportunity to parameterize something is always taken. But writing the same stupid loop to delete something from a slice is also unclear and complicated. The point isn't that generics are bad, just that they should be used judiciously.

Re: Go 1.18

#189

Post by gnoack »

HideousKojima wrote: post #181
gnoack wrote: post #175

The general excitement about generics on this thread makes me uneasy. Please keep in mind that generics are a pretty big hammer - they can add a lot of complication if not used with caution. Only use a language feature if you absolutely must.

I see it the other way around, generics reduce complication and allow for code that's a lot more elegant and simple than without. It definitely adds complexity on the compiler side of things, but using them in C#, TypeScript, and Java has been only a plus. Unless you count that time I tried to do stuff with generic interfaces in Entity Framework Core, but that was EF Core's fault as opposed to generics's.

...and that time when people reinvented boolean expressions and their combinatorics under the disguise of Predicate and Matcher, making test errors hard to comprehend for very little additional benefit. etc etc

There is also the problem that people don't generally have a good grasp on how to use type bounds[1] correctly... I believe Go avoids the worst of it through its simple type system, but still... this complicates a language significantly.

[1] https://docs.oracle.com/javase/tutorial/java/generics/bounde...

Re: Go 1.18

#190

Post by mindwok »

AaronFriel wrote: post #64

My favorite feature is a tiny, couple line bug fix that I pushed hard to get included during the feature freeze. Full details here, but a summary is below: https://github.com/golang/go/issues/51127 For the past ~8 years, many hundreds of people reported on GitHub - and likely many multiples more have encountered and not reported - a program that didn't work with the error "cannot unmarshal DNS..." This error seems to…

That was a good read. Well done pushing that forward, I believe it was the right position to take.
Post reply on HN