Ball is in your court now typescript-on-the-serverside ppl!
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
Go Replaces Interface{} with 'Any'
31–40 of 481 posts
Re: Go Replaces Interface{} with 'Any'
#32This is fantastic. It'll make Go feel much less weird. eg from the diff:
[]interface{}{1, 2.0, "hi"} -> []any{1, 2.0, "hi"}
Re: Go Replaces Interface{} with 'Any'
#33Loading this commit in safari almost killed my phone
Works fine for Firefox on a Pixel 6. Took a couple of seconds to load then smooth (ginormous) scrolling was available.
Same for an old Android phone with outdated Snapdragon 660 I use to test app performance bottlenecks. Except this one took 4 secs to load.
Re: Go Replaces Interface{} with 'Any'
#34Ball is in your court now typescript-on-the-serverside ppl!
I don't see how they're competing, TypeScript can still share code between client and serverside, go "can't".
They're not exclusive to each other, routing "form submissions" though a ts verification layer and then down to Go makes sense to me if you need the Go performance but want to share things client and server side.
Also, application servers are cheap, persistent, fast and durable storage isn't, these won't be written in TS.
TL;DR: different problem domains, not important
Re: Go Replaces Interface{} with 'Any'
#35Earlier quoted context omitted.
AFAICT, its usage is not restricted to generics. It seems to be suggested to use anywhere you would use interface{}. For the release announcement: https://news.ycombinator.com/item?id=29556646
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?
Re: Go Replaces Interface{} with 'Any'
#36Re: Go Replaces Interface{} with 'Any'
#37[deleted]
Re: Go Replaces Interface{} with 'Any'
#38I like it, interface{} always felt unlike anything else in go other than structs.
Why does 'interface{}' feel unlike 'interface{String() string}' to you? Just because it doesn't have a method? You know that you can inline non-empty interfaces, too? func foo(x interface{String() string}) string { return x.String() }
I think you (and the other reply) are for some reason confusing my complaint as functional rather than purely syntactical.
Re: Go Replaces Interface{} with 'Any'
#39Earlier quoted context omitted.
How is generics not a big enough change to warrant 2.0? Edit: I’m impressed generics aren’t a breaking change! I thought this changed Interface{} to Any as a breaking change
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 breaking changes. For a language? Silliness. Your version is not really telling you the main things you care about.
It's much much more useful to the users to say, 2.0 introduced generics, it's distinct. If it's like other languages, generics changes the code people generate a lot, libraries start looking significantly different. It's very distinct, and if that is simply in version 1.18.0 or whatever, that is super bad usability from a language perspective.
Re: Go Replaces Interface{} with 'Any'
#40So now that go has generics and modules, is there an up-to-date intro for writing cutting-edge Go code for people who are already pretty familiar with the older styles?
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.