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

101–110 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#101

Post by Vanclief »

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.

I used to really hate that. After reading this amazing post https://middlemost.com/failure-is-your-domain I created a module that makes this bearable https://github.com/Vanclief/ez

Re: Go Replaces Interface{} with 'Any'

#102

Post by masklinn »

jchw wrote: post #84
welder wrote: post #70

Good, now we just need the ability to declare function parameters and return values non-nullable (Forbid passing nil into a function, and declare a function will never return nil). That would get rid of the "panic: runtime error: invalid memory address or nil pointer dereference" errors. https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...

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.

Re: Go Replaces Interface{} with 'Any'

#103

Post by post-it »

linkdd wrote: post #66
robto wrote: post #57

Earlier quoted context omitted.

In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.11, respectively[0]. In Clojure land they just say 1.x, even when large new features are added. I like this because it emphasizes the community's commitment backwards compatibility, which I greatly value. I've spent a good deal of time writing Javascript, where library developers…

> In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.8, respectively. 17 -> 1.17, 11 -> 1.8, this is bothering me way to much for no good reason.

I don't think 11 ever referred to 1.8 generally, but for the longest time the `openjdk-11-*` packages in one of the Ubuntu LTSes (18.04?) actually installed Java 8 for some reason.

Re: Go Replaces Interface{} with 'Any'

#104

Post by erdaniels »

takeda wrote: post #59
moth-fuzz wrote: post #54

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…

Isn't Any essentially: type Any interface{} ?

It's a type alias so it's

    type any = interface{}
That means they're interchangeable compared to defining a new type.

Re: Go Replaces Interface{} with 'Any'

#105

Post by Laremere »

takeda wrote: post #59
moth-fuzz wrote: post #54

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…

Isn't Any essentially: type Any interface{} ?

Close, it's:

    type Any = interface{}
That is, it's an alias and casting is not necessary.

Re: Go Replaces Interface{} with 'Any'

#106

Post by peoplefromibiza »

the_duke wrote: post #58
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.

Emulating sum types in languages without pattern matching is extremely awkward, to the point of being almost useless. type Result[T] struct { ok: *T err: error } Great, so how do you work with it? * You can have a `ok()` getter that returns `*T`. Now you you need an `if x != nil` * `isOk()` + `isErr()` * `unwrap() T`, which panics on errors * `split() (*T, err)` that splits into separate values, especially awkward si…

you can map on ok which is an alias for map_ok and then map_err for errors and or_else or_throw etc.

that's similar to what Java does with the Optional type, not great, but not bad either

the alternative is checking for nulls which is worse in any possibile way

I usually implement something like Kotlin Result when I have to code in Java

with a couple of static helpers to build the result: Result.success(T) Result.failure(Throwable t)

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/

also Result in Rust has been an inspiration

https://doc.rust-lang.org/std/result/enum.Result.html

Re: Go Replaces Interface{} with 'Any'

#107

Post by throwaway894345 »

takeda wrote: post #59
moth-fuzz wrote: post #54

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…

Isn't Any essentially: type Any interface{} ?

I'm pretty sure it's an alias, so: `type any = interface{}`.

`type any interface{}` would declare a new type, while an alias is exactly another name for the same type.

Re: Go Replaces Interface{} with 'Any'

#108

Post by mappu »

brabel wrote: post #65

Their code is full of things like: type fileOps []any // []T where T is (string | int64) Go does not have neither generics nor union types. So people have to do this kind of thing :( I feel sorry for them. Reminds of Java 4 (15 years ago or something) where code was full of this crap: List /* */ values; Map /* */ map; Some devs spent a whole week doing nothing other than removing those commented out generic type decl…

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.

Re: Go Replaces Interface{} with 'Any'

#109

Post by nvarsj »

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!

Yes, please, the iferr pattern drives me nuts. While I built a few years of my career on golang, I'm absolutely sick of the language at this point. At least we finally get generics.

Re: Go Replaces Interface{} with 'Any'

#110

Post by aliswe »

saagarjha wrote: post #45
jcadam wrote: post #40

Earlier quoted context omitted.

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.

about 10 years ago I had a discussion with an interviewer (he was actually consultant manager) who said "c# and Java are exactly the same in terms of runtime architecture" which I very much disagreed with when speaking strictly, which wasn't appreciated.
Post reply on HN