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

41–50 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#41

Post by travisd »

woah wrote: post #36
jamespwilliams wrote: post #31

Earlier quoted context omitted.

I’m not a typescript person, but to be fair to typescript, its type system is still much more expressive than Go’s, even with the generics addition

Typescript is stricter and safer while also being less obtrusive than Go

This isn't super clearcut. Typescript has lots of footguns and famously says that soundness is not one of their driving factors. There are lots of ways to devolve to accidental implicit any's (even with the no implicit any strict rule turned on).

Of course, Go makes zero attempt to enforce nullability (nilability?) in its type system... so... win some, lose some I guess.

Re: Go Replaces Interface{} with 'Any'

#42

Post by hamburglar »

mseepgood wrote: post #23
maxk42 wrote: post #20

Earlier quoted context omitted.

I tried doing the modules tutorial a while back but had difficulty with the directory structure. At some point I think the "recommended" directory structure became mandatory and I don't think my personal dev environment ever quite lined-up with it. Perhaps I should wait another year then buy a book.

Modules don't require any particular directory structure, just a go.mod at the root of your project.

That’s “a particular directory structure” that conflicts with many already-existing projects. What if I have a mostly-java project that has a couple bits of go code buried in it that I want to use as modules? Break it up into multiple repos for no good reason? No single tool should be acting like it owns the root directory of my repo.

Re: Go Replaces Interface{} with 'Any'

#43

Post by mseepgood »

eweise wrote: post #35
mseepgood wrote: post #8

Earlier quoted context omitted.

Yes, it's not restricted to generics. But the reason the alias was introduced is generics. Because they use interfaces to specify bounds (constraints) for type parameters (bounded polymorphism): [T fmt.Stringer], [T io.Reader], ... So an unbounded type parameter is [T interface{}], or [T any] when using the shorter alias. It's a type alias / predeclared identifier defined in the universe scope: type any = interface{}

Couldn't unbounded just be [T]? Why the extra typing?

No, that would be a parsing ambiguity with arrays. And the consistency of type parameter lists with normal parameter lists where types are mandatory is an additional benefit.

Re: Go Replaces Interface{} with 'Any'

#44

Post by handrous »

eweise wrote: post #35
mseepgood wrote: post #8

Earlier quoted context omitted.

Yes, it's not restricted to generics. But the reason the alias was introduced is generics. Because they use interfaces to specify bounds (constraints) for type parameters (bounded polymorphism): [T fmt.Stringer], [T io.Reader], ... So an unbounded type parameter is [T interface{}], or [T any] when using the shorter alias. It's a type alias / predeclared identifier defined in the universe scope: type any = interface{}

Couldn't unbounded just be [T]? Why the extra typing?

Makes it much less likely someone will accidentally define a type as "any".

Re: Go Replaces Interface{} with 'Any'

#45

Post by saagarjha »

jcadam wrote: post #40
vlunkr wrote: post #29

Earlier quoted context omitted.

While it's good to get up-to-date, I don't think anyone should go re-write code or radically change their programming style to use generics. There's no need to over-complicate things. Anywhere that you're either copy-pasting a bunch, or using code generation might be a good fit for generics.

Just you try not being up-to-date in a coding interview.

I’ve found out that it’s possible to be too up-to-date for some coding interviews.

Re: Go Replaces Interface{} with 'Any'

#46

Post by pawelmurias »

keithnz wrote: post #39
philwelch wrote: post #7

Earlier quoted context omitted.

In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…

> Can upgrade without having to deal with breaking changes

This is actually very important. If something is a major change or not is pretty subjective.

Re: Go Replaces Interface{} with 'Any'

#47

Post by meowface »

jonathankoren wrote: post #26
ignoramous wrote: post #24

Earlier quoted context omitted.

0ver is parody, right?

Well there’s a joke somewhere. Less has my favorite version numbering system. Sequential. Latest stable release: Version 598 https://www.greenwoodsoftware.com/less/

My favorite has become just making the version number the release date.

Re: Go Replaces Interface{} with 'Any'

#49

Post by mseepgood »

hamburglar wrote: post #42
mseepgood wrote: post #23

Earlier quoted context omitted.

Modules don't require any particular directory structure, just a go.mod at the root of your project.

That’s “a particular directory structure” that conflicts with many already-existing projects. What if I have a mostly-java project that has a couple bits of go code buried in it that I want to use as modules? Break it up into multiple repos for no good reason? No single tool should be acting like it owns the root directory of my repo.

The root of the Go project with the go.mod file doesn't have to be the root of the repository.

Re: Go Replaces Interface{} with 'Any'

#50

Post by linkdd »

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!

I cannot wait for the Result monad.

The state of error handling in Go at the moment is embarrassing at best.

Post reply on HN