Live data from Hacker News

Go Replaces Interface{} with 'Any'

github.com

181–190 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#181

I'm not sure I like this change. I liked interface{} since it just works out naturally from Go's relatively simple type system, and anyone could come to the conclusion without actually being told "use interface{} to represent any possible value" just by having an understanding of that type system. Adding what is simply a type alias, multiple words for the same underlying concept, to me just feels like jargon. I admir…

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 {
    }
versus:

    func doSomething[X any, Y Fooer[any]](v X, src Y) error {
    }
the signatures can get long pretty quickly when you have more than one type parameter.

Re: Go Replaces Interface{} with 'Any'

#182
HackerNews on TypeScript:

"Like OMG we need to get rid of Any, it is such a catch all bullshit workaround for a very serious problem, I have developed billions of applications across every domain and like OMFG this is garbage, THIS IS NOT TYPED, WE SIMPLY NEED TO REMOVE ANY AS IT MEANS ANY GARBAGE AND KIDS JUST USE IT".

HackerNews on Go (6 years later):

"AT LAST! WOOOO HOOO ANY, WOW"

Me:

"what?"

HackerNews:

"Go"

Me:

"OK?"

HackerNews:

"Yes"

Re: Go Replaces Interface{} with 'Any'

#183
post #84

Earlier quoted context omitted.

I’d kill for union types as well. … and pattern matching. Maybe just some extensions for `switch`. … and one of the `try` proposals. That having been said… I do appreciate that Go has gotten where it is today by being radically simple, and that a lot of extreme care needs to be done to add new features to the language. It’s hard to draw a firm line in the sand. I feel like all of these features would work great toget…

> I’d kill for union types as well. > … and pattern matching. Maybe just some extensions for `switch`. Go has type switches which are… ok. If it were possible to “close up” interfaces and type switches took that in account (match completeness) you’d be done about done, you would not have the structural / patterned unpacking but that’s probably less of a concern.

the fact that the set of types that can satisfy an interface is open is the source of their power. "closed interfaces" are broadly an antipattern in Go.

Re: Go Replaces Interface{} with 'Any'

#184
post #39

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…

> Sure, but semantic versioning really is the wrong kind of versioning to use for a language.

A language or API (things you program against) are pretty much the things for which SemVer makes sense.

> The major version should represent major language changes, not whether its a breaking change or not

I don’t care if changes are “major”, I care if the code I wrote for version X is expected to need modification to work correctly in version Y. SemVer gives me that, Subjective Importance Versioning does not.

Re: Go Replaces Interface{} with 'Any'

#185
post #39

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…

I thank Go team, that the major version was not increased. You can't imagine how much wider adoption of generics will be as compared if Go went to version 2.0 There are thousands of under-educated and overly-cautious software development managers who would prevent their teams from upgrading to a major version of Go until it is "proven". When it comes to developers there are two types who read changelogs and would know their tool well and take advantage of every small change in each minor version and then there are those who are there for the money, they will find out about a new feature only if manager instructs them to use it.

Re: Go Replaces Interface{} with 'Any'

#186
post #39

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…

I would definitely consider a language to be an API. Using semantic versioning makes perfect sense; because it communicates to consumers of the language which versions will require them to change their source code and which will not.

Re: Go Replaces Interface{} with 'Any'

#187
post #39

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…

I agree. It's a bit odd that I just learned generics were added. I expect minor bumps in language versions to be uneventful. Additionally, I expect a language to essentially never introduce breaking changes, so semantic versioning isn't really telling me anything.

Re: Go Replaces Interface{} with 'Any'

#188
post #108

Earlier quoted context omitted.

Go has had generic List and Map since before Go 1.0, though. It's really interesting you used those as your examples because that need was fully met in a type-safe way already, and other examples are actually much rarer to come by.

The behavior of builtin maps can’t be customized at all. Now at least it’s possible to define a sorted or threadsafe or immutable map with a typesafe API, though it takes replacing all reads and writes with method calls.

Not being able to customize built-in containers is a huge win in terms of readability though. Principle of least surprise and all.

If I see a map or slice I know exactly how it behaves, how much memory it consumes, what the runtime behavior is. If you make those generics instead then I have literally no fucking clue what's going on.

Re: Go Replaces Interface{} with 'Any'

#189
post #39

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…

> Sure, but semantic versioning really is the wrong kind of versioning to use for a language.

I don't agree. I usually don't care so much when a particular feature was introduced into a language (and if I do, it's usually a Wikipedia search away). I mostly care whether or not code written assuming version X can be compiled with version Y of the compiler. Semantic versioning can tell me the latter. Making versioning arbitrarily depend on what someone considers a "big" feature doesn't help me.

Re: Go Replaces Interface{} with 'Any'

#190
post #137

Earlier quoted context omitted.

But why is it satire? It makes a lot of sense for projects that don't want to commit to a stable API.

For projects like React Native, which claim production-ready and are presumably quite stable in practice, you’re back to version numbers being meaningless, except with the added bonus it’s not even useful for marketing..

You make a good argument. Anything that keeps the marketers away does seem like a pretty good feature.
Post reply on HN