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

Go Replaces Interface{} with 'Any'

github.com

Post reply on HN
Print view View original

371–380 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#371

Post by zerocount »

drvd wrote: post #329
lolive wrote: post #227

Earlier quoted context omitted.

Disclaimer: I am totally newbie in Go. But quite experienced in Java and Js/Ts. I never jumped the Go bandwagon because of the lack of generics. Can I now try Go? The following article seems to say that the lack of other features can be frustrating (the lack of lambdas and the lack of the functional handling of collections seems problematic to me) Also I wonder whether the language has a IDE support as good as Intell…

> I am [...] quite experienced in Java and Js/Ts. > I never jumped the Go bandwagon because of the lack of generics. > Can I now try Go? Probably no. You still would be very disappointed. Go's take at writing and maintaining software often is pretty repugnant to people with a strong Java or JavaScript mindset. If missing user defined parametric polymorphism ("generics") was a reason to not even _try_ it you will be o…

I don't understand why you're lumping JavaScript in with Java. These are very different languages and are likely to produce very different mindsets.

Re: Go Replaces Interface{} with 'Any'

#372

Post by detaro »

zerocount wrote: post #371
drvd wrote: post #329

Earlier quoted context omitted.

> I am [...] quite experienced in Java and Js/Ts. > I never jumped the Go bandwagon because of the lack of generics. > Can I now try Go? Probably no. You still would be very disappointed. Go's take at writing and maintaining software often is pretty repugnant to people with a strong Java or JavaScript mindset. If missing user defined parametric polymorphism ("generics") was a reason to not even _try_ it you will be o…

I don't understand why you're lumping JavaScript in with Java. These are very different languages and are likely to produce very different mindsets.

Is either of the mindsets close to the Go mindset?

Re: Go Replaces Interface{} with 'Any'

#373

Post by quietbritishjim »

necovek wrote: post #361
halfdan wrote: post #336

Earlier quoted context omitted.

It's clear the py2 to py3 migration was painful but I'm curious to hear how you would apply "they should fork / rename the language" here. To me it just feels like semantics. They said "here's a new major version of python" when they could also have said "we have forked python 2 and we're calling it python 3. We think it's better and we will probably abandon python 2 at some point".

(FWIW, "semantics" would be "what it means", so I figure that's not what you wanted to say: from your example, I guess you are saying it's more that it's a different wording — syntax? — for the same meaning) But it's about setting expectations. The only problem I ever had with py2 to py3 migration was that it was even possible to have the same codebase run against both, when languages are incompatible to such a degre…

Semantics refers specifically to meaning of words/language. If you say "it's only semantics" then it probably means you both understand and agree on the concepts but not the meaning of the words surrounding those concepts. That applies in this case, with the concept being breaking changes to a language along the lines of Python 2->3, and the terms being "version change" and "new language".

Re: Go Replaces Interface{} with 'Any'

#374

Post by jcelerier »

Veelox wrote: post #214
weatherlight wrote: post #203

Earlier quoted context omitted.

I agree. I don't understand why the designers wouldn't want the language to be expressive. Wouldn't it be better to have an expressive language with conventions than one that's as rigid as it is today?

In C++ there could be 7 or 8 different ways go about implementing similar functionality. This is powerful in that it lets you do exactly what you want because each of those ways is subtly different and sometimes you need each one. Go's proponents think it's okay to be a bit less powerful so that there is only 1 maybe 2 ways to do something. This makes code at different companies more similar. It also mean that a new…

Yet every year I onboard new grads on very c++y projects with no restrictions on features used and they manage just fine.

Re: Go Replaces Interface{} with 'Any'

#375

Post by Cthulhu_ »

nvarsj wrote: post #109
kbd wrote: post #32

This is fantastic. It'll make Go feel much less weird. eg from the diff: []interface{}{1, 2.0, "hi"} -> []any{1, 2.0, "hi"} Now that Go is going to have generics, all we need is sugar syntax for early return on error -- like more modern languages such as Rust and Zig have -- and Go may finally be pleasant to program in!

Yes, please, the iferr pattern drives me nuts. While I built a few years of my career on golang, I'm absolutely sick of the language at this point. At least we finally get generics.

What alternative do you propose?

Re: Go Replaces Interface{} with 'Any'

#376

Post by pawelmurias »

pishpash wrote: post #207
zemo wrote: post #181

Earlier quoted context omitted.

with generics you wind up with two parameter lists, and type parameters have metatypes. All type parameters need to have a metatype, and the metatype `any` comes up a lot. Once you start using generics you'll start to feel the pain of writing `interface{}` in those signatures, especially when you are dealing with functions like this one: func doSomething[X interface{}, Y Fooer[interface{}]](v X, src Y) error { } vers…

Does a personal (not language-wide) type any = interface{} not work, if you felt that strongly?

That's an extra line of boilerplate. If someone for some reason wants uglier and longer code then can still use interface{}

Re: Go Replaces Interface{} with 'Any'

#377

Post by Cthulhu_ »

ogogmad wrote: post #364

Going to be downvoted for this, but it would be cool if Go had operator overloading. That way, you could write matrix code in it. I think if Go did this, the language could end up being used in computer graphics and Deep Learning. Oh, and maybe this goes against the Go ethos, but Python has a library called Sympy for Computer Algebra, and it's quite nice. It clearly relies on operator overloading. I'm guessing this w…

I hear what you're saying, but why make one language look like another when that other language is more suitable for those purposes (graphics and deep learning)? Isn't Python the go-to language for deep learning? It's probably better to stick to that one, because the field itself is hard enough already - learning another language on top will just put people off.

Re: Go Replaces Interface{} with 'Any'

#378

Post by Cthulhu_ »

welder wrote: post #70

Good, now we just need the ability to declare function parameters and return values non-nullable (Forbid passing nil into a function, and declare a function will never return nil). That would get rid of the "panic: runtime error: invalid memory address or nil pointer dereference" errors. https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...

> Good, now we just need the ability to declare function parameters and return values non-nullable

But that's already possible, just declare arguments and return values as values instead of references. I mean you'll get the zero value if you don't use those functions properly, but those won't cause nil pointer dereference errors.

I mean, it's a tradeoff between performance and developer competency. To be harsh, I think nil pointer dereferences are developer error, not a flaw in the language.

Re: Go Replaces Interface{} with 'Any'

#379

Post by Cthulhu_ »

kbd wrote: post #32

This is fantastic. It'll make Go feel much less weird. eg from the diff: []interface{}{1, 2.0, "hi"} -> []any{1, 2.0, "hi"} Now that Go is going to have generics, all we need is sugar syntax for early return on error -- like more modern languages such as Rust and Zig have -- and Go may finally be pleasant to program in!

> all we need is sugar syntax for early return on error -- like more modern languages such as Rust and Zig have -- and Go may finally be pleasant to program in!

Can you provide an example? What's wrong with `return err`? That's a very explicit early return on error, no magic or language features (= added complexity) needed.

Re: Go Replaces Interface{} with 'Any'

#380

Post by ogogmad »

Cthulhu_ wrote: post #377
ogogmad wrote: post #364

Going to be downvoted for this, but it would be cool if Go had operator overloading. That way, you could write matrix code in it. I think if Go did this, the language could end up being used in computer graphics and Deep Learning. Oh, and maybe this goes against the Go ethos, but Python has a library called Sympy for Computer Algebra, and it's quite nice. It clearly relies on operator overloading. I'm guessing this w…

I hear what you're saying, but why make one language look like another when that other language is more suitable for those purposes (graphics and deep learning)? Isn't Python the go-to language for deep learning? It's probably better to stick to that one, because the field itself is hard enough already - learning another language on top will just put people off.

I appreciate the broad philosophy of Go, which is that it's a simple language. Much simpler than Python which (and this is subjective) has made some questionable design choices. I also like how it's not exotic or surprising; you can just get straight to hacking.

I also like that Go is fast. It appears that some Python code is being rewritten in Go to make it go faster. Python's slowness is a problem in both the areas I've mentioned, and I know the usual workarounds.

Post reply on HN