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

91–100 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#91

Post by cortesoft »

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…

Wait, why wouldn’t it matter for a language? I want to know if I can compile my existing project with the new version… isn’t that an important thing to know?

Re: Go Replaces Interface{} with 'Any'

#92

Post by egeozcan »

hbn wrote: post #62
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!

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…

I kind of understand what you mean, as it's similar to what happened with prototypes and the late-comer class syntax in JavaScript, and in that case, it was a net positive change as most would probably say.

Let's see how this plays out.

Re: Go Replaces Interface{} with 'Any'

#93

Post by 13415 »

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

Re: Go Replaces Interface{} with 'Any'

#94

Post by kbd »

linkdd wrote: post #86
the_duke wrote: post #58

Earlier quoted context omitted.

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…

The Rust Result type has: - map / map_err - and_then / or_else - unwrap / unwrap_or And countless of other functions making it very practical to chain computations without having to pattern match anything. I do the same in Erlang/Elixir. In Golang, I need to check every function call, and if I want to know where an error come from, I need to wrap it in an errors.New() because no exceptions = no stacktrace

> and if I want to know where an error come from, I need to wrap it in an errors.New() because no exceptions = no stacktrace

Zig manages to provide traces with very little overhead:

https://ziglang.org/documentation/master/#Error-Return-Trace...

I am baffled as to why error handling in Go remains so impoverished.

Re: Go Replaces Interface{} with 'Any'

#95

Post by [deleted] »

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…

[deleted]

Re: Go Replaces Interface{} with 'Any'

#96

Post by ViViDboarder »

meowface wrote: post #47
jonathankoren wrote: post #26

Earlier quoted context omitted.

Well there’s a joke somewhere. Less has my favorite version numbering system. Sequential. Latest stable release: Version 598 https://www.greenwoodsoftware.com/less/

My favorite has become just making the version number the release date.

See CalVer. The date is definitely helpful for something with fairly stable APIs where breaking changes aren’t really happening.

Perfect for things like Ubuntu, pytz, and ca-certificates.

Less for something like a library who’s API could change and break your implementation.

Re: Go Replaces Interface{} with 'Any'

#97

Post by egeozcan »

linkdd wrote: post #86
the_duke wrote: post #58

Earlier quoted context omitted.

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…

The Rust Result type has: - map / map_err - and_then / or_else - unwrap / unwrap_or And countless of other functions making it very practical to chain computations without having to pattern match anything. I do the same in Erlang/Elixir. In Golang, I need to check every function call, and if I want to know where an error come from, I need to wrap it in an errors.New() because no exceptions = no stacktrace

I don't see why that wouldn't be possible to implement now that the generics are here.

Re: Go Replaces Interface{} with 'Any'

#98

Post by catillac »

dilyevsky wrote: post #69
saagarjha wrote: post #45

Earlier quoted context omitted.

I’ve found out that it’s possible to be too up-to-date for some coding interviews.

Lol so true, go a little overboard with fancy language features and people think you’re a cowboy coder

I was in an interview not long after format strings in Python came out (for example, print(f”Hello, {name}”) rather than print(“Hello, %s”, name)) and the interviewer thought I was confusing languages and features, asserted this fact strongly, and was pretty surprised when it worked, but I think overall I lost points because the interviewer lost face.

C’est la vie.

Re: Go Replaces Interface{} with 'Any'

#99

Post by danudey »

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.

Clarification:

* Java 8 is Java 1.8.0

* Java 11 is Java 11.0.11 (at the moment)

* Java 17 is Java 17.0.1 (at the moment)

SunOS/Solaris is what I use when I want to get nerd-rage mad about minutae: https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history

Re: Go Replaces Interface{} with 'Any'

#100

Post by linkdd »

egeozcan wrote: post #97
linkdd wrote: post #86

Earlier quoted context omitted.

The Rust Result type has: - map / map_err - and_then / or_else - unwrap / unwrap_or And countless of other functions making it very practical to chain computations without having to pattern match anything. I do the same in Erlang/Elixir. In Golang, I need to check every function call, and if I want to know where an error come from, I need to wrap it in an errors.New() because no exceptions = no stacktrace

I don't see why that wouldn't be possible to implement now that the generics are here.

Which is exactly why I said:

> I cannot wait for the Result monad.

Generics make this possible, and will be a huge improvement to Go's error handling.

I'm not saying it will solve everything, but it's a huge step nonetheless.

Post reply on HN