Live data from Hacker News

Go Replaces Interface{} with 'Any'

github.com

221–230 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#221
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…

define a "major" language change, then. after that, get everyone to agree on that definition.

that's why semver works; the definition of major change is defined, and that's when you update the major version number.

Re: Go Replaces Interface{} with 'Any'

#222

Earlier quoted context omitted.

"Tell the user nothing" is your favorite system? Especially, like, what if you release a bugfix for a significantly old version? Do you give it an up-to-date number? Do you not give it a number at all? (Also I see a 581.2 on that page.)

Upgrade

> Upgrade

Upgrading is the problem in this scenario. Let's say 727 is the modern version. If users upgrade to 728, when 728 is based on 402, we have an issue.

Re: Go Replaces Interface{} with 'Any'

#223
post #124
post #93

Earlier quoted context omitted.

It makes no sense to replace a meaningful and helpful criterion - whether it breaks code or not - by some purely subjective assessment of what's a "major change." That just leads to usual version creep, from "Go 2.2" to "Go 3.0", to "Go 4.0", to (inevitable) "Go 10", "Go 11", "Go 11 Pro", "Go 11 Ultimate Edition",...

It could be worse, they could start naming these "Go WXGA+", "Go i99900kf", and "Go for Women".

Go 3.2 Gen 2x2!

Re: Go Replaces Interface{} with 'Any'

#225

gofmt -w -r 'interface{} -> any' src Is this a real command? If so, I’m very impressed. Is there any equivalent for c++ and other languages?

Yep, it's a rewrite rule: https://pkg.go.dev/cmd/gofmt

The combination of unambiguous syntax and consistently-formatted code results in rewrites producing meaningful diffs (most of the time).

Re: Go Replaces Interface{} with 'Any'

#227

It's a type alias, introduced for generics. By the way, Go 1.18 Beta 1 is released (with generics): https://groups.google.com/g/golang-announce/c/eAjK4Oezs_A

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 IntelliJ with Java (safe function extraction, type-safe autocomplete)

Would the local gurus here please comment?

[the idea for me is to replace my tricky shell scripts with Go scripts.]

https://medium.com/webstep/a-java-developers-adventures-thro...

Re: Go Replaces Interface{} with 'Any'

#228

After generics (coming soon), a proper sum type and then I'll shut up.

I just want to write f(g(), h()) without nine lines of useless noise that editors don’t know how to hide. I guess it might be possible to write a generic function that uses panic/defer to return an error from a subexpression.

Nobody woken up in the middle of the night to debug your code wants you to write that.

Re: Go Replaces Interface{} with 'Any'

#229
post #62
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!

It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Learning Go really reframed my concept of what an interface is, and I thought that using an empty interface to represent "any type" was kind of ingenious, and helps reinforce its ethos. An empty interface can represent any type because every type inherently implements an interface with no methods. An…

This is valuable for a learning language and for learning in general. But it’s the kind of concept that ought to be abstracted away, in my opinion.

Re: Go Replaces Interface{} with 'Any'

#230
post #196

Earlier quoted context omitted.

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.

I hate this pattern too but there's not "no good reason", there's a specific reason why it's like this, and it's a conscious design choice. When you call `go get somedomain.com/whatever/thing`, what it does is makes an HTTP request to that URL, then looks for a ` ` tag on the page telling it where to download the module. Check out the source of any Go project on github and you'll find the relevant ` ` tag. Here's the…

The whole meta tag thing seems to break the “principle of least surprise,” as I had no idea that was how go get worked.
Post reply on HN