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

351–360 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#351

Post by asimpletune »

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…

Yeah, I think you’re talking about the “vanity bit”

Re: Go Replaces Interface{} with 'Any'

#352

Post by neop1x »

papito wrote: post #78
linkdd wrote: post #50

Earlier quoted context omitted.

I cannot wait for the Result monad. The state of error handling in Go at the moment is embarrassing at best.

People downvote it, but it's true. 2/3 of your Go code is `if err` blocks. And the way you have to chain the error messages to make the stack make any kind of sense is just maddening.

We often have errors handled. In contrast to many Java codes just spitting unhandled exception stacktraces or crashing completely.

Re: Go Replaces Interface{} with 'Any'

#353

Post by xmprt »

mseepgood wrote: post #14
nkozyra wrote: post #9

I 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 people agree that those look similar however the problem is that the first is a common practice while the latter is something that no one in their right mind would do. If people replace the second with something like Stringer, then the first should be replaced too.

Re: Go Replaces Interface{} with 'Any'

#354

Post by BatteryMountain »

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 actually agree with you.

I'm mostly a C# developer that uses a ton of generics and when I tried Go previously I was disappointed that it didn't have generics. But I continued on. And so I found a handful of other things that would irritate me or would be an inconvenience versus doing the same thing in C#. So generics alone is not the main problem here, it is going from a C#/Java mindset to a Go mindset. In some way we would probably get bored with Go because it is so simple/easy and not much to mess up, versus the super complex object empires in C#/Java land.

So the problem is not really a problem, go is just a different tool for a different kind of problem or if your brain works in a specific way - but I wouldn't call it a problem at all. In a way, go is what Buddhism is to other (more fully featured) religions. I think if you get proficient with you can probably have a very peaceful programming experience and not fight against the system (like in Java, half the battle is just battling the tooling).

Thanks for bringing this up, will give Go another look again, its been a while!

Re: Go Replaces Interface{} with 'Any'

#355

Post by coldtea »

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…

>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.

A language update comes with the most fundamental set of libraries and APIs: the standard library (doubly so in Golang, which has a lot of batteries included).

It also potentially affects the behavior (if there are breaking changes) of all other third party libs.

The "silliness" part is a non sequitur from what proceeded it (and the following arguments don't justify it either).

>Your version is not really telling you the main things you care about.

The main thing (nay, only thing) I care about (for my existing code) from a language update is whether there were breaking changes.

I could not care less to have reflected in the version number whether a big non-breaking feature was introduced.

I can read about it and adopt it (or not) whether there's a accompanying big version number change or not.

>It's much much more useful to the users to say, 2.0 introduced generics, it's distinct.

That's quite irrelevant, isn't it?

It's not useful to users that follow the language (page, forums, blogs, etc.) and would already know which release introduced generics.

And it's also not useful to new users that get started with generics from day one of their Go use either.

So who would it be useful to?

Such a use would make the version number the equivalent of a "we got big new feature for you" blog post.

Re: Go Replaces Interface{} with 'Any'

#356

Post by BatteryMountain »

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!

Can you kindly post a snippet of what you want the early return on error syntax sugar to look like? I'm trying to map it in my mind on how I'd do it in C# and how it would look in Go.

Re: Go Replaces Interface{} with 'Any'

#357

Post by ainar-g »

jamincan wrote: post #246
blahgeek wrote: post #201

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?

'cargo fix' will upgrade your code from one Rust edition to the next as well as apply corrections for lint warnings.

cargo fix is closer to (and possibly inspired by?) go fix[1], imo.

[1]: https://pkg.go.dev/cmd/go#hdr-Update_packages_to_use_new_API...

Re: Go Replaces Interface{} with 'Any'

#358

Post by outadoc »

DarylZero wrote: post #202
setr wrote: post #137

Earlier quoted context omitted.

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..

It's not meaningless -- the meaning is that there are bugs. That is why the version can indefinitely approach -- but never reach -- 1.

In opposition with SemVer projects, which... ...don't have bugs?

Re: Go Replaces Interface{} with 'Any'

#359

Post by ainar-g »

RunOutOfMemory wrote: post #280
ibraheemdev wrote: post #277

Earlier quoted context omitted.

What about it?

interface{} -> any struct{} -> ?

We use the alias "unit", like lalaithion has said before, in many projects. It's a bit annoying to declare it in every package though. Hopefully, there'll be an official alias in the future.

Re: Go Replaces Interface{} with 'Any'

#360

Post by ainar-g »

jjice wrote: post #67
AtNightWeCode wrote: post #56

Like it! Now, can they continue to add more “useless” improvements like while-loops and so on.

Doesn't 'for' work as 'while' if you only give it a condition in go? I haven't written much, so correct me if I'm wrong.

It does and it's enough for "while". What I do miss sometimes is the repeat-until / do-while loop. You can emulate it with "for" currently, but it's awkward.
Post reply on HN